-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Make yaws:accumulate_header/1 conforming to RFC #415
Comments
If you have multiple functions trying to contribute headers, you might consider using
Regarding "Vary" vs "vary", Yaws performs normalization of header names. Additionally, for some common headers like "Vary", you can use the atom |
Sorry my original report may not be clear but I am referring to response headers. |
Sure, but as you probably know Yaws supports multiple approaches for server applications functionality, including |
To simplify imagine an
Only the last vary header will be sent back because of the faulty last-write-win by |
Many headers allow you to sent as multiple headers with the same name for example,
Vary
,Cache-Control
,Accept-Encoding
,Set-Cookie
etc etc. Not all of them are handled correctly.I discovered this discrepancy while experimenting with the Vary header. In my case a request is passed through multiple functions. One function adds a Vary header for security reasons but the header is gone because a later function accidentally overrides it owing to
yaws:accumulate_header/1
's last-write-win semantics.There is also the issue of not normalising the header names. For example, "Vary" and "vary" are different headers per Yaws.
The text was updated successfully, but these errors were encountered: