Re: [apps-discuss] Spencer Dawkins' Discuss on draft-ietf-appsawg-http-problem-02: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Mark,

On Thu, Dec 17, 2015 at 6:05 PM, Mark Nottingham <[e-mail]> wrote:

> Hi Spencer,
>
> On 18 Dec 2015, at 1:38 am, Spencer Dawkins <[e-mail]>
> wrote:
>
> > I'm elevating this to a (late) Discuss, because I haven't heard anything
> > back, and didn't want the document approved without having a (short)
> > discussion. I'll be back to Yes after that.
> >
> > In this text,
> >
> >   The "status" member duplicates the information available in the HTTP
> >   status code itself, thereby bringing the possibility of disagreement
> >   between the two.  Their relative precedence is not clear, since a
> >   disagreement might indicate that (for example) an intermediary has
> >   modified the HTTP status code in transit.  As such, those defining
> >   problem types as well as generators and consumers of problems need to
> >   be aware that generic software (such as proxies, load balancers,
> >   firewalls, virus scanners) are unlikely to know of or respect the
> >   status code conveyed in this member.
> >
> > I understand what you're saying about a mismatch being possible, and some
> > of the possible reasons why that might happen, but isn't this saying that
> > anyone who can understand the "status" member should prefer its value
> > when there's a mismatch (because it's less likely to have been dorked
> > with by an intermediary - or is that even true)?
>
> It really depends on what their purpose is. The HTTP status might be
> updated because of legitimate HTTP machinery -- e.g., by a cache (304), or
> a proxy (various things like proxy auth, disconnected operation). The
> status member is there to preserve the original intent of the author, and
> also for convenience (e.g., when a message is persisted, often the status
> is lost).
>
>
> > So, the situation looks to me, like there's a MUST
> >
> >   The status member, if present, is only advisory; it conveys the HTTP
> >   status code used for the convenience of the consumer.  Generators
> >   MUST use the same status code in the actual HTTP response, to assure
> >   that generic HTTP software that does not understand this format still
> >   behaves correctly.
> >
> > that some intermediary can dork with, so the result violates the MUST,
> > and we really can't tell the receiver what you should do at that point.
> > "Gee, I guess you're gonna have to flip a coin to decide who to believe"
> > would be sad, but it would be more guidance than the document has now :-)
>
> If you're implementing generic HTTP software, you're going to be using the
> HTTP status. If you're interpreting the HTTP problem itself, you're
> probably going to pay attention to the one in-document, IF you pay
> attention to it at all.


Thanks for the explanations.

I'll clear this Discuss, but would love it if you could say something like
what you've told me in the document.


> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I've wished this mechanism was available, a few times already.
> >
> > In this text,
> >
> >   If such additional members are defined, their names SHOULD start with
> >   a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist
> >   of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be
> >   serialized in formats other than JSON), and SHOULD be three
> >   characters or longer.
> >
> > are there any benefits to not conforming to these SHOULDs? For example,
> > would you really need to have a two-character member name, and you'd fail
> > if the member name was three characters long? ("Why are these not
> > MUSTs?")
>
> Those requirements are to make it compatible with the XML mapping. They're
> SHOULDs because someone might be really, really sure that their problems
> will never be used in XML.
>
> Cheers,
>
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>