Subject: p1: generating "internal" errors

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 14:07:52 +1000

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?

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.

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

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 09:03:54 +0200

On Sat, Apr 20, 2013 at 02:07:52PM +1000, Mark Nottingham wrote:
> 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 :-(

> 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.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 17:06:08 +1000

> invent their own code, this is pretty bad :-(

I'm thinking more about client libraries than intermediaries.

> 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...

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 09:14:59 +0200

> 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.

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Apr 2013 14:19:43 +1000

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>).