Re: p1: generating "internal" errors

[Mark Nottingham <[e-mail]>]

OK. I think I'll work on a separate draft to do this.

My main concern is developers that overload existing codes in an inappropriate ways, and the pseudo-standardisation of implementation-specific ones (as we're starting to see in <http://en.wikipedia.org/wiki/List_of_HTTP_status_codes>).


On 20/04/2013, at 5:14 PM, Willy Tarreau <[e-mail]> wrote:

> On Sat, Apr 20, 2013 at 05:06:08PM +1000, Mark Nottingham wrote:
>> 
>> On 20/04/2013, at 5:03 PM, Willy Tarreau <[e-mail]> 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
> 
> 

--
Mark Nottingham   http://www.mnot.net/