How to indicate success after `202` + monitor URL

[fbender]

The spec mentions the 202 Accepted status as preferred method to annouce asynchronous processing at the endpoint.

The response body SHOULD include a URL that can be used to monitor the status of the request.

(based on https://github.com/converspace/webmention/blob/22c98da9df068d854b0f630737ae5ed44d69a728/README.md)

Firstly, the spec should mention if a client is expected to follow (or never follow) the provided monitoring URL. Is the Webmention request finished with only posting to the endpoint? Or is a requesting client expected to check for successful submission?

Secondly, the spec should include what answers are expected when trying to access the mentioned URL. Until now, only error codes are mentioned, and it is unclear whether these status codes should be sent from the endpoint only or are also valid at the monitoring URL. Also, what status code is expected to be sent when processing was successful (200 OK)? What status code is sent while the process is not finished yet:

• another 202 with the same processing URL, maybe with a Retry-After header that must be obeyed
• a 102 Processing but this is only specced in WebDAV, needs some timeout status code if processing cannot be finished within a certain time slot; keeps connection open (may not be desired)
• other option is 303 with the same URL as Location, may lead to DoS when client is redirected immediately (as is mostly the case)
• or some timeout error (5xx, 4xx) + Retry-After, may lead to confusion

And lastly, what content (if any) is sent when the processing was successful? Are clients expected to ignore the body of a 200 OK in the context of Webmentions?

---

Additional note: The spec mentions an example URL for process monitoring:

http://alice.host/webmentions/222

Is 222 supposed to be a unique ID for every Webmention request? This should be mentioned in the spec. I'd also replace that with an alphanumeric ID to indicate that IDs can be of arbitrary (text) form, e.g. http://alice.host/webmentions-queue/IsmNqd8G.

---

I'd be happy to fix these issues myself. Just let me know so I can prepare a PR.

[aaronpk]

Currently the whole concept of a status URL is completely optional, which means there is no meaningful content that can be returned other than "yep working on it" (202). In practice, people have returned everything from a plaintext sentence to JSON to a full HTML page as the response of the webmention. I think it's important to leave that option open.

It would be useful to standardize the way the status URL works. However that is probably better off as an extension spec, or at least better developed initially as an extension and later incorporated into the core webmention spec. Feel free to write something up on the indiewebcamp wiki if you have experience with creating and/or consuming these status URLs.

You could submit a change for an alphanumeric ID, but I would avoid putting the word "queue" in the URL as that makes implications about the underlying implementation.