test suite bug?
Closed this issue · 2 comments
While testing my implementation with https://websub.rocks/hub/104, after clicking the 'Unsubscribe' button (using a public hub) while 'Waiting for unsubscription to be confirmed' I get the following error:
Error!
The verification request was missing the hub.lease_seconds parameter
The spec has the following to say about lease_seconds (5.3 Hub Verifies Intent of the Subscriber):
hub.lease_seconds
REQUIRED/OPTIONAL. The hub-determined number of seconds that the subscription will stay active before expiring, measured from the time the verification request was made from the hub to the subscriber. Hubs MUST supply this parameter for subscription requests. This parameter MAY be present for unsubscribe requests and MUST be ignored by subscribers during unsubscription.
In short, does the test suite, acting as a subscriber here, violate the last MUST?
Another potential bug, this time at https://websub.rocks/subscriber/100. My original POST subscription request (as defined in # 5.1 Subscriber Sends Subscription Request) gets answered with a 400 code. The body includes the following explanation:
{"error":"verification_failed","error_description":"The callback URL did not confirm the verification request.","code":0,"callback_response":false,"type":"error"}
This seems in violation of the spec (specifically the last quoted MUST NOT):
If a hub finds any errors in the subscription request, an appropriate HTTP [RFC7231] error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text, used to assist the client developer in understanding the error. This is not meant to be shown to the end user. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers). However, since verification and validation of intent are asynchronous steps that logically begin after the HTTP response has been returned, the HTTP response MUST NOT depend on the process or outcome of verification or validation.
It seems like the test should return 202, and only then hit my callback. I discovered this as my test procedure actually only exposes the callbacks after a 202 response is received. I'm going to fix that as it depends on the (localhost) subscriber outracing the (external) hub in getting them up (which is not guaranteed, even though it's likely), but that doesn't mean there isn't a bug on the test suite side too.
I see the test suite has its own repo. Moved this into two issues there: