relax requirements on hypertext in 3/4/5xx error responses

[julian.reschke@…]

Bjoern H. notes:

The fallback requirement

Unless the request method was HEAD, the representation of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s), since most user agents do not understand the 308 status code yet. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

strikes me as a bad idea. It's a transient problem so it should be conditioned and how widely supported this is, and it's only useful if you have some HTML implementation on the other end or an interactive user; a web service not meant for interactive use where you can be sure that the code is supported, because, say, you control the client, is unaffected, and if you add that as another exception you basically end up saying you can do this so your site works better with legacy clients in some situations and making your site work good is probably a good idea, so I'd prefer just saying that. I don't really want to ponder whether I should send this hypertext response in response to an OPTIONS request in 2015, just because your specification says I should.

[julian.reschke@…]

From [1508]:

Align description of 307 with 302 (307 isn't "new" anymore) (related to #332)

[julian.reschke@…]

From [1515]:

State that the Content-Type describes the payload only one (related to #332)

[julian.reschke@…]

From [1516]:

demote SHOULD for payload on 201; it doesn't make sense for PUT (related to #332)

[julian.reschke@…]

proposed change for p2

[julian.reschke@…]

From [1521]:

relax payload requirements for 301/302/307 (addresses #332)