While I agree it has advantages, it is also buggy.

>From https://www.rfc-editor.org/rfc/rfc9110.html#name-methods:

* “the method token is case-sensitive”.

So, you need to remove ‘string-upcase’.

* Additional methods, outside the scope of this specification, have been 
specified for use in HTTP. All such methods ought to be registered within the 
"Hypertext Transfer Protocol (HTTP) Method Registry", as described in Section 
16.1.

(Just a reminder, not a bug with the proposed new parse-http-method.)

If it’s something application-specific, I propose naming the method something 
like
“APP-METHOD” (where APP = name of APP, METHOD = WAIT / SUBSCRIBE / ...), to 
avoid potential conflicts.

* “method = token”

“token” is defined in https://www.rfc-editor.org/rfc/rfc9110.html#name-tokens.

So, there are some limitations on what strings are valid method names that you 
need to verify. For example, suppose that someone uses “GET\0sneaky” as header, 
and the Guile code places some limits (in terms of 403 forbidden) of what can 
be read. “GET\0sneaky” passes through because it’s not “GET”, “HEAD” etc.. 
Let’s say the actual response is constructed by C code, so Guile passes the 
method to the C-code as a 0-terminated string (as is conventional) and the 
C-code then interprets “GET\0sneaky” as “GET\0” and sends the response while it 
shouldn’t.

(I don’t know if this particular situation can happen because perhaps 
parse-http-method is always used in a context where the string is for some 
reason already a token, but that’s not something to rely upon)

* A recipient SHOULD parse a received protocol element defensively, with only 
marginal expectations that the element will conform to its ABNF grammar and fit 
within a reasonable buffer size.

(quoting this for the “conform to grammar” part, not the “buffer size part”)

(With regards to the first point) this paragraph SHOULD be ignored, this way 
leads to continued violations of the grammar and potential security problems 
(see example in previous point). Postel’s law is a mistake.

Best regards,
Maxime Devos

Reply via email to