Re: BCP56bis: advice for using status codes in applications

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 <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 <mailto: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 <mailto: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 <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 <mailto: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/ <https://www.mnot.net/>
>> 
>> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer