what should senders do when they receive a 3xx response from the webmention endpoint?

[aaronpk]

Currently the spec gives no guidance to webmention senders on what they should do if the webmention endpoint returns a 3xx response.

If a browser sees a 301/302 response when posting a form, they will redirect to the new URL and make a GET request. If webmention senders do the same, they will end up not sending the webmention to the redirected URL.

HTTP defines 307/308 response codes to indicate the client should re-send the same POST request to the new URL.

• What is the theoretical "proper" behavior?
• What do implementations currently do? And do they consider it a bug? (please link to an issue tracker if so)

[sandhawke]

Is there anything that could go wrong from a client following redirects in sending a webmention? (assuming it does the usual things to avoid loops)

[tantek]

Sounds like from analysis that webmention endpoints MUST NOT return 301/302 since there is no way for a webmention sender to (HTTP) conformantly recover from that and not drop the webmention on the floor. (this seems testable for webmention endpoints, perhaps as part of existing tests)

Thus "proper" behavior for a webmention endpoint is that it MUST use 307/308 response codes instead, and if it cannot do that, it MUST NOT redirect at all and MUST handle the webmention at the originally POSTed URL. (maybe an optional test for this? where the tester can provide a URL that they think will return a 307/308 for the test suite to try?)

[aaronpk]

@sandhawke if the client is a browser, then what you'd expect to happen when submitting a form posting to a webmention endpoint (like many existing examples have on their post permalinks) is the server should send a Location header to redirect the browser somewhere to show the result of the webmention. That means HTTP 301/302 should not be used to tell a client where to re-send the POST request to, which also mirrors browsers' existing behaviors of handling this response code.

Since HTTP already defines HTTP 307/308 as a redirect and maintaining the HTTP verb it seems that webmention senders should only send the POST to the new location when the response is 307/308.

[sandhawke]

To rephrase: the odds are better that a sender will correctly follow a 307/308 than a 301/302, so if a server wants to redirect it should use 307/308 instead of 301/302. But that's really about #90.

For this issue, I'd say a sender MUST follow 307 and 308 redirects, at least N hops (1? 2?).

For 301/302 I guess I'd say senders "SHOULD NOT" follow them, because if anyone does follow them then servers are more likely to erroneously use them, because they'll seem to be working. That's a bit of twisted argument, though, and if I were implementing, I'd be strongly tempated to just let my library do its thing and follow them.

[gRegorLove]

My initial thought is redirected endpoints should return 301/302 for GET requests only, and 307/308 for POST requests only.

Senders SHOULD check for a 301/302 during endpoint discovery and follow them before sending. If they don't do that and receive a 307/308 when sending the POST, they MUST follow the redirect and send the POST again to the final endpoint.

Edit 2: Re-reading, I misunderstood the 301/302 vs 307/308 distinction.

I think redirected endpoints SHOULD return 307/308 for GET and POST requests.

Senders SHOULD check for 3xx during endpoint discovery and follow them before sending. If they don't do that and receive a 307/308 when sending the POST, they MUST follow the redirect and send the POST again to the final endpoint.

If a sender receives a 301/302/303 from a POST, they should GET the specified Location.

Edit 1: I've filed an issue to handle the redirect-during-discovery for ProcessWire Webmention module: gRegorLove/ProcessWire-Webmention#13