LeaYeh / webserver

MIT License
4 stars 1 forks source link

[TODO] Header Field Validator whitelist #87

Open leske42 opened 1 week ago

leske42 commented 1 week ago

These are the header fields we need to parse:

Others will get ignored, either because they do not concern us or because it would be too complicated to implement and the RFC allows for this as seen in following cases:

[Accept]

A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.

[Accept-Charset]

If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a 406 (Not Acceptable) response, or disregard the header field by treating the resource as if it is not subject to content negotiation.

[Accept-Language]

A request without any Accept-Language header field implies that the user agent will accept any language in response. If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a 406 (Not Acceptable) response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example).

This means, if they send one of the above and we do not parse it, two things can happen: we either happen to coincidentally support what they want, and then all is good. OR we happen to not support it, but the RFC allows for sending default stuff in that case. So because of this parsing is not needed.

And for Accept-Encoding we need to consider:

An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response. If an Accept-Encoding header field is present in a request and none of the available representations for the response have a content-coding that is listed as acceptable, the origin server SHOULD send a response without any content-coding.

leske42 commented 5 days ago

[UPDATE] From RFC 9110 (obsoletes 7232)

"A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT evaluate the conditional request header fields defined by this specification"

So seems like unless we do the cache from the bonus we should not implement If-Modified-Since and If-Unmodified-Since