Content bug: Wrong header-types for Transfer-Encoding and Trailer headers

[singla-shivam]

What page(s) did you find the problem on?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding

Specific page section or heading?

Transfer-Encoding and Trailer headers

What is the problem?

In the docs, the header type for Transfer-Encoding and Trailer headers is marked as Response header.

What did you expect to see?

They should have been marked as General header

Did you test this? If so, how?

References and research:-

• In RFC 7230, it is nowhere mentioned that these Transfer-Encoding and Trailer headers are response headers. Everywhere sender-receiver is mentioned. (Argument from- TE header is explicitly said as request header).
• In the Wikipedia List of HTTP header fields, Transfer-Encoding and Trailer headers are mentioned separately in request and response headers.
• I myself checked running cat my_file | curl -T- http://127.0.0.1:8080 to see if the transfer-encoding is applied to the request or not. Result- yes it is applied.
• Stackoverflow QA references:-
  • https://stackoverflow.com/q/45917169/11642727
  • https://stackoverflow.com/q/692910/11642727
  • https://stackoverflow.com/q/62484479/11642727

[hamishwillee]

Thanks @singla-shivam . I think you're definitely right, and these are not "response headers".

The definition of general headers here is "apply to both requests and responses, but with no relation to the data transmitted in the body.". Trailer fits into that category, but I'm not sure that Transfer-Encoding does, as it describes the content of the chunked payload. But then it isn't a representation/entity header either since it applies to the encoding during transport, not the final encoding.

Even if not quite right though, I think more clear to users than having "response header".

@sideshowbarker What do you think? I'm wondering if we should really use "General header" (ever) since it isn't in the spec, and instead mark things as both Request or Response header if they are both.

Specs

• Transfer-Encoding
• Trailer spec

[sideshowbarker]

@sideshowbarker What do you think? I'm wondering if we should really use "General header" (ever) since it isn't in the spec

Yeah, I think we should avoid using any term that’s not used in the current HTTP spec.

and instead mark things as both Request or Response header if they are both

Yes, that seems to me like the right thing to do.

Trailer fits into that category, but I'm not sure that Transfer-Encoding does, as it describes the content of the chunked payload.

I’m not aware of browsers ever sending a Transfer-Encoding request header — but as far as for the general case in HTTP, I see the last paragraph of the https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.1 section the spec says this:

A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).

That seems to imply the spec at least doesn’t rule out the possibility for transfer coding to specified in a request (and thus for a request to have a Transfer-Encoding request header — since that’s the mechanism for specifying the transfer coding).

[hamishwillee]

@sideshowbarker What do you think? I'm wondering if we should really use "General header" (ever) since it isn't in the spec

Yeah, I think we should avoid using any term that’s not used in the current HTTP spec.

Excellent. Given this is a change in "what we do", who should we ask for approval from? Because we should do this at least a bit "globally".

[hamishwillee]

@Elchi3 Chris suggest you might be a good person to advise re #4889 (comment) above. Specifically, in the HTTP Header info tables we refer to them being as request, response, general and (possibly) representation/Entity headers.

We use "General" to be mean "either request or response header based on context, unless is to do with payload representation". But the docs are specific in that they say General is not a spec term - so perhaps we should just have header type as both in a comma separated list?

E.g. like

[Elchi3]

hm, yes, it's possible we took this definition from an older RFC (https://datatracker.ietf.org/doc/html/rfc2616#section-4.5) when we first wrote the MDN HTTP docs.

I think your suggestion to just have header types in a comma separated list makes a lot of sense. It is more clear anyways, "general" is quite generic :)