Subject: [HTTP/1.1] method length and 501 Not Implemented

From: Karl Dubost <[email-masked]>
Date: Tue, 12 Mar 2013 19:07:47 -0400

Hi,

in "3.1.1.  Request Line"
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.1.1
There is a strange sentence:

   HTTP does not place a pre-defined limit on the length of a request-
   line.  A server that receives a method longer than any that it
   implements SHOULD respond with a 501 (Not Implemented) status code.

a method "longer"?
The way I understand the sentence is that if the server has implemented the methods, let's say:

	GET, HEAD, OPTIONS

so 7 characters for the longest method. If the server receives a method which is 

	BABOOZILLA

it sends a "501 Not Implemented", but then why not for a 2 characters long method like

	YO

What was the reason for this specific requirement on the length of the method.

-- 
Karl Dubost
http://www.la-grange.net/karl/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 13 Mar 2013 00:19:31 +0100

>[...] but then why not for a 2 characters long method like
>
>	YO

The text above discusses length limits and reactions to them; it is not
meant to say anything about other reasons for sending 501. If the server
does not recognise the "YO" method then it should also reply with 501,
as per the definition of the 501 status code.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Karl Dubost <[email-masked]>
Date: Tue, 12 Mar 2013 19:26:38 -0400

> as per the definition of the 501 status code.

Yes exactly, but then why being specific on the length of the *method*? 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.6.2

It seems the spec could get rid of that specific sentence without loosing meaning.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 12 Mar 2013 23:29:26 +0000

I think it is simply proposing a simple strategy to deal with what could 
otherwise be a buffer overrun attack on method.

e.g. instead of waiting until you have accumulated the entire method 
string, you can fail early if the length is greater than any you 
recognise.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 13 Mar 2013 00:45:53 +0100

>http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.6.2

It discusses the request line which consists of method, address, and
version information, and if you want to add a reminder that addresses
can be very long, as the text does, then you end up with discussing
the method separately aswell (and it's conceivable that a server might
pick some other code for this case without the recommendation, just as
it might implement worse behavior, like having a fixed buffer for the
method that overruns when using a overly long method). I don't think
it's phrased very well, but I also don't think it's very strange.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 13 Mar 2013 20:58:14 +1300

On 13/03/2013 12:29 p.m., Adrien W. de Croy wrote:
>
> I think it is simply proposing a simple strategy to deal with what 
> could otherwise be a buffer overrun attack on method.
>

Yes. This is more about the servers which are relay agent and implement 
the "YO" / unknown methods by relaying it upstream. In order to do 
anything with the URL portion of the request-line they have to cope with 
methods being too long.

Amos

> From: "Karl Dubost"