- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 27 Mar 2020 14:54:49 +1100
- To: Colm Divilly <colm.divilly@oracle.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
Hi Colm, > On 26 Mar 2020, at 11:27 pm, Colm Divilly <colm.divilly@oracle.com> wrote: > > Hi Mark, > thanks for taking the time to review this, based on your & Amos' [1] feedback, I've submitted a new draft: Great. > > Regarding this question: > >> More generally, when someone needs to convey more refined information about what caused an error, the advice we give is to put that information in the response body or a response header. Did you consider that approach? > > Yes, we include information in both the response header and the response body, we have found it to be largely ineffective. Our experience is that tools and humans see 500, think 'I know what that means...' and proceed to filing a problem report/complaining to the wrong party far too often. Also the extra information in the response header and body may end up being lost in the journey back to the client/monitoring tools. For example the access log will only show the status code, custom error pages may hide extra information in the response body. I understand and sympathise. However, if the bar for getting a new status code is "that's what people pay attention to", we're going to run out of status codes pretty quickly (which is the underlying concern with lots of these discussions). Also, the more status codes we mint, the more confusion there is about which one to use -- a phenomenon we already see a lot of. That doesn't mean that we can't or won't standardise this -- just that we need to be thoughtful about it. > https://datatracker.ietf.org/doc/draft-divilly-user-defined-resource-error/ > > Changes in this draft: > > - Use 5NN instead of 555 through out > - Remove 555 from the draft name > - Explain use of 5NN: https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-1 > - Explain why 500 Internal Server Error does not suffice: https://tools.ietf.org/html/draft-divilly-user-defined-resource-error-00#section-2.1. TLDR, folks only see the status code in the response, they ignore anything else is my experience > - Do not indicate that the draft seeks to update RFC 7231 Thanks, that's a very good start. > Regarding the following point: > >> I agree this condition is potentially applicable to any resource, but it might fall afoul of another principle that we haven't written down as well -- that HTTP focuses on standardising the interface to the resource, not its implementation details (which this seems to be about). Roy might have some more thoughts here. > > I see this proposal as enhancing the interface rather than clouding it with implementation details. When an error occurs, then very often some follow up action needs to be taken. Often that action is to file a problem report or examine some logs. The purpose of this status code is to help inform the client with whom to file the problem report or which logs to examine. > > This proposal provides a clear classification for tools and humans, that can inform their decision about to how to deal with the error condition. > > This falls outside what HTTP does or should specify. I see this proposal as a tiny layer atop the HTTP protocol to help with this pain point. > > I still feel this a pretty specialised use-case at this time and there likely is not enough consensus to standardise this approach, which is why I filed it as an informational draft. My hope with submitting the original draft was that others with similar requirements might come across the draft and choose to harmonise on using 555 as the status code for this condition, and that over time a consensus might build that it would be appropriate to try get it standardised. > > I understand now that this approach is not in line with RFC 7231, so I've amended the draft to avoid preferring (squatting on) any particular status code. Thanks again. Regarding next steps (chair "hat" on) -- I'd love to hear what other WG participants (and people who don't participate here regularly, of course) think about this. One of the things we look for is level of interest, as well as level of agreement. Normally, Tommy and I would probably ask you to present at the next HTTP Working Group meeting in Madrid. It's not clear what's going to happen with that meeting, but I suspect that one way or another we'll be having a WG meeting soon, if only virtually, and we can probably have a discussion there. Between now and then, hopefully we'll see more mailing list discussion. Is that workable for you? I'm not sensing a need to get a decision quickly on your part, but if that's not the case, please say so. I've also added this to our Watch List so we remember to check in on it from time to time: https://github.com/httpwg/wiki/wiki/WatchList Cheers, > > Regards, > Colm > > [1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0244.html > >> On 26 Mar 2020, at 03:49, Mark Nottingham <mnot@mnot.net> wrote: >> >> Hi Colm, >> >> For reference, the guidance for new status codes is here: >> https://httpwg.org/specs/rfc7231.html#considerations.for.new.status.codes >> >> I agree this condition is potentially applicable to any resource, but it might fall afoul of another principle that we haven't written down as well -- that HTTP focuses on standardising the interface to the resource, not its implementation details (which this seems to be about). Roy might have some more thoughts here. >> >> More generally, when someone needs to convey more refined information about what caused an error, the advice we give is to put that information in the response body or a response header. Did you consider that approach? >> >> Cheers, >> >> P.S. As an aside - we discourage people from "squatting" on status codes like this because it makes it harder to use them in standards later, and they are a relatively scarce resource. Please don't use it until it has been standardised, and in the future, it's best to make proposals along the lines of "a new 5xx status code" rather than a specific number. Thanks. >> >> > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 27 March 2020 03:55:11 UTC