RE: Custom HTTP methods in web module

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8765 bytes --]