Re: BCP56bis: advice for using status codes in applications

When particular instances of this have come up in the past, the discussion
seems to hinge on whether a generic HTTP implementation would evolve to do
something meaningful with the new status code other than what it would do
with the x00 one. Generic implementation in this case being something that
wasn't designed for the purpose of implementing the new application-on-http
which can certainly encode the signal in headers or body. I think the text
is consistent with that pattern - perhaps it should call it out a little
more explicitly (i.e. what would an off the shelf library do differently in
the face of 275 vs 200 and a header in this case?)

On Wed, Jan 9, 2019 at 2:12 PM Michael Sweet <msweet@apple.com> wrote:

> FWIW I am 100% OK with the text as-is, and this is exactly the approach
> IPP uses - 200 (really any 2xx status) for any IPP POST, unless we need
> something "generic" at the HTTP level:
>
> - Authentication (401/403)
> - Bad request where the client sends something other than a proper
> application/ipp message body (400)
> - Bad/wrong URI (404)
> - Expect: 100-continue (100)
> - Redirection (3xx)
> - Upgrade to TLS (426 and 101)
> - Something bad on the server/printer (5xx)
>
> In the case where the client needs to interact with resources (icons, ICC
> profiles, localization files, camera video feeds, etc.), the client just
> does regular HTTP GET (or PUT, for upload) requests with the standard HTTP
> semantics.
>
> We occasionally add new IPP status codes, but have never needed new HTTP
> status codes.
>
> This approach has worked well for us for over 20 years now, with (no shit)
> tens of billions of printers and clients, both locally and over the
> Internet, spanning almost 50 specifications/RFCs that have extended IPP to
> support many different architectures and technologies.
>
>
> On Jan 9, 2019, at 1:47 PM, Tommy Pauly <tpauly@apple.com> wrote:
>
> I believe the text that started this discussion comes from section 4.6
> (HTTP Status Codes):
> https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08#section-4.6
>
> The specific text of interest is:
>
>    Instead, applications using HTTP should specify the implications of
>    general classes of responses (e.g., "successful response" for 2xx;
>    "client error" for 4xx and "server error" for 5xx), conveying any
>    application-specific information in the message body and/or HTTP
>    header fields, not the status code.  [RFC7807 <https://tools.ietf.org/html/rfc7807>] provides one way for
>    applications using HTTP to do so for error conditions.
>
>    There are limited exceptions to this; for example, applications might
>    use 201 (Created) or 404 (Not Found) to convey application semantics
>    that are compatible with the generic HTTP semantics of those status
>    codes.  In general, though, applications should resist the temptation
>    to map their semantics into fine-grained status codes.
>
>
> Thanks,
>
> Tommy
>
>
>
> On Jan 9, 2019, at 10:39 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
>
> Can you reference the specific text in 56bis that is being discussed.. it
> would help focus the discussion. thanks!
>
> On Wed, Jan 9, 2019 at 12:37 AM Mark Nottingham <mnot@mnot.net> wrote:
>
>> Promoting to a new thread, as suggested.
>>
>> I explored the thinking behind this in a blog post a while back:
>>   https://www.mnot.net/blog/2017/05/11/status_codes
>>
>> Julian, do you disagree with that, or just how it's expressed here?
>>
>>
>> > On 8 Jan 2019, at 8:31 pm, Julian Reschke <julian.reschke@gmx.de>
>> wrote:
>> >
>> > 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.
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>