- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 8 Jul 2010 11:49:39 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jul 08, 2010 at 11:37:41AM +0200, Julian Reschke wrote: > On 08.07.2010 11:03, Willy Tarreau wrote: > >On Thu, Jul 08, 2010 at 10:57:05AM +0200, Julian Reschke wrote: > >>On 08.07.2010 02:13, Mark Nottingham wrote: > >>>That's roughly what I mean by private use -- i.e., don't ever serialise on the wire. > >> > >>If it's never on the wire, do we really care? > >> > >>If APIs need a value range that is guaranteed to be never used in > >>HTTP/1.1, simply pick values that can't be put on the wire, such as< > >>0 or> 999. > > > >or maybe simply add the precision that codes< 100 and>= 600 will never > >be emitted over the wire ? > > I really don't see the benefit. Maybe we want to use them in HTTP/1.2? > > What's wrong with < 0 or > 999? Nothing, I'm just suggesting to document what is currently practiced. If some products already use 6xx to report internal statuses, either we enforce 999 and we remind them that they don't comply to the new spec, or we clarify the spec to consider what's already deployed, meaning 1xx-5xx on the wire and the rest for internal use. I personally have no preference, I've never used internal codes within the 0..999 range myself, but it's nice not to be too much aggressive against existing products' practices ;-) Regards, Willy
Received on Thursday, 8 July 2010 09:50:13 UTC