Re: Restricting the HTTP method definition

On Aug 21, 2013, at 8:18 AM, James M Snell wrote:

> The connection with what I described in that blog post is that many
> implementers have, apparently, take a number of liberal shortcuts in
> terms of how they parse and accept http methods.

As is allowed by HTTP, though some of those "shortcuts" are
actually security holes in that implementation.

> Node's parser, for
> instance, will immediately error out if it receives a method that
> doesn't start with an alpha character (which is reasonable). It also
> does not support the use of any non-alpha character other than "-"
> (dash). Their implementation also chooses not to support extension
> methods because the implementers feel there is no way of supporting an
> arbitrary unknown set of tokens in a performant way... and truthfully,
> because there is no upper bound on the length of the methods and
> because there is a significantly large value space, they do have a
> point.

No origin server is required to implement all methods.  That choice
has nothing to do with limitations in the protocol itself, which
would prevent ANY implementation from supporting longer methods
or gatewaying to distributed object systems.

> 
> Now, I did say right up front that this is a fairly minor issue, and
> if it doesn't happen, so be it. But the restrictions I suggest ought
> to make it at least some degree easier for implementations to
> generically handle extension methods in a performant manner.. while at
> the same time more accurately reflecting the reality of what many
> implementers are already doing.

Rubbish.  There are plenty of implementations to choose from that
do not have protocol limitations baked into stupid parsing code.
Any implementation can choose a maximum method length that it is
willing to support -- systems that depend on longer methods will
use different software.  This has zero effect on performance
because the request line is going to be read as one buffer that
has to be very long (to support the request-target) regardless.

The rationale for method is given in

http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/23/p2-semantics.html#method.overview

It would be really helpful if folks here would understand that
typical browser traffic represents less than 1% of implementations.
Yes, it is the bulk of traffic, but that doesn't mean the rest
of HTTP is defined by it.  We optimize for the common case and
let the uncommon cases fend for themselves; we do not kill the
uncommon cases because we cannot know what good things would
be broken by doing so.

....Roy

Received on Wednesday, 21 August 2013 19:14:30 UTC