Re: HTTP request validation guidelines for implementers

On Fri, Jul 09, 2021 at 08:51:07PM +0000, Joćo Penteado wrote:
> On Friday, July 9th, 2021 at 15:45, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> > Am 09.07.2021 um 19:51 schrieb Joćo Penteado:
> >
> > > ...
> > >
> > > 2. If the most servers out there adopt the same validation order, clients will
> > >
> > > gain additional information unavailable before. If, for instance, every server
> > >
> > > checks URI length before checking payload size, and I get a "413 Request Entity
> > >
> > > Too Large" error, I would know for sure that my URI length is fine and all the
> > >
> > > previous checks passed successfully.
> > >
> > > ...
> >
> > You lost me here.
> >
> > If a client sends both a too large URI and a too large request body,
> >
> > why does it matter in practice which one is reported first? At the end
> >
> > of the day, to fix the issue, both problems need to be resolved, no?
> >
> > Best regards, Julian
> 
> You're correct, in pratice, the validation order doesn't matter as much as
> what is being validated, as the client would still have to address all issues
> in order to have its request accepted. Which is why I believe that reason no. 1
> is a more relevant argument for having a well definied validation order.

It's difficult to impose an order, as it will really depend on the
implementation. Parsing errors will almost always trigger as soon as
the rest of the message is not parsable anymore. But even then, you
could find implementations that stop on the first bad character in a
header field name while others will first tokenize in lines and only
then split each line into name+value.

Then you can have significant differences in ordering between the layer
of evaluation. Message delimitation is critical, but assuming that
components are properly formed, some implementations will have
opportunities to validate some fields on the fly (e.g. content-length,
transfer-encoding while others will rather postpone this to after the
whole header block is parsed.

The URI length or header length limitation issues will be even less
enforceable because they do not indicate something invalid in the message
but that one element in the chain couldn't cope with them. So this can be
triggered by the 3rd gateway in the chain after all other elements were
properly validated, just like they can be triggered by the very first
gateway before any other element is validated.

In any case you should consider that an error report doesn't imply that
once fixed everything else will work, but that *at least* this one needs
to be addressed. Thus the order doesn't really matter in the end.

Hoping this helps,
Willy

Received on Saturday, 10 July 2021 22:35:59 UTC