- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 20 Apr 2013 09:14:59 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Sat, Apr 20, 2013 at 05:06:08PM +1000, Mark Nottingham wrote: > > On 20/04/2013, at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote: > > > On Sat, Apr 20, 2013 at 02:07:52PM +1000, Mark Nottingham wrote: > >> p1 3.2.4 requires that a syntax violation in a received response be turned > >> into a 502 (Bad Gateway) status code. > >> > >> I'm not necessarily against it, but I think if we're going to take this > >> approach to errors in received responses, it should be systematic, and we > >> should recommend that others do it too. Currently, a lot of people are > >> inventing new pseudo status codes to fill this role. > >> > >> What do people think? > > > > haproxy does exactly this right now (502) and I was not aware that people > > invent their own code, this is pretty bad :-( > > I'm thinking more about client libraries than intermediaries. OK. As was once discussed here, if we insist on no status code in the range 100-599 to be randomly picked by a developer, we're leaving enough room for libraries to do what they want without risk of interference. > >> This might not result in any changes in our specs beyond adjusting language > >> in a few other places to do the same thing. I could see writing a separate > >> spec for a header that described the type of error, though. > > > > Good idea. Alternatively the reason code after the 502 could be modulated too. > > That is discarded in some circumstances, and in any case we shouldn't > encourage people to start using it for semantically significant things... Agreed. Willy
Received on Saturday, 20 April 2013 07:15:22 UTC