W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: Working Group Last Call: draft-ietf-httpbis-bcp56bis-08

From: Roberto Polli <roberto@teamdigitale.governo.it>
Date: Tue, 8 Jan 2019 14:29:37 +0100
Message-ID: <CAMRHeuwve4=ra0RvyuvCVOM8_f+7RQ8-289rDC6EHO=q3n=S1g@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi @all,

Il giorno mar 8 gen 2019 alle ore 10:34 Julian Reschke
<julian.reschke@gmx.de> ha scritto:
> On 2019-01-08 10:11, Mark Nottingham wrote:
> > ...
> >>>> It talks about status codes in general; that includes new ones, no?
> >>> Potentially, but new status codes are required to be generic, not application-specific, so it ends up in the same place. Status codes are *not* a guaranteed end-to-end signal; they can (and often are) superseded by HTTP components in the middle.
> >>
> >> Under certain well-understood circumstances, by design, or when there is a bug. My point is that they usually are reliable when the actual origin servers gets to respond.
> >
> > Well-understood by implementers, perhaps, but often not application designers.
> >
> >> I'm concerned that the current text will cause people to stuff all information into header fields or the payload, and just send 400.
> >
> > Yes. Unless you want to intentionally trigger generic HTTP processing based upon a chosen status code, that's best practice.
> > ...
> This is really news to me. This probably requires a new top-level thread.
FWIW I agree with Julian.

Have a nice day,
Received on Tuesday, 8 January 2019 13:30:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 8 January 2019 13:30:13 UTC