3 ms·
Here's the RFC ref for anyone wanting to check it out: https://www.rfc-editor.org/rfc/rfc9110#field.vary https://www.rfc-editor.org/rfc/rfc9110#field.vary Noti
by brabel 3y ago
Here's the RFC ref for anyone wanting to check it out: https://www.rfc-editor.org/rfc/rfc9110#field.vary https://www.rfc-editor.org/rfc/rfc9110#field.vary
Notice that this is the HTTP "Semantics" RFC, not the "core" one (Message and Syntax) which is the venerated RFC-7230 [1] which is indeed quite simple for such a widely used protocol.
This RFC only defines a handful of "header fields", almost all of which necessary for actually being able to "frame" (find the beginning and end, applying decoding if specified) the HTTP message : https://www.rfc-editor.org/rfc/rfc7230#section-8.1 https://www.rfc-editor.org/rfc/rfc7230#section-8.1
[1] https://www.rfc-editor.org/rfc/rfc7230 https://www.rfc-editor.org/rfc/rfc7230
- Joker_vD 3y agoSee, the caching mechanism in HTTP/1.1 is actually quite nicely designed in the sense that you can completely ignore it: don't look at any caching-related fields, always pass the requests up and the responses down — and it will be correct behaviour. But when you start to implement caching, well, you have to implement it, even the inconvenient but mandatory parts. Yes, I know (and personally experienced) that most clients forget to include "Vary" field, or don't know that it exists, or the problem that this header solves exists) but when they do include it, they actually mean it and rely on it being honoured, one way or another. PS. By the way, 7230 is obsoleted, you're supposed to use 9112 now.
- brabel 3y agoRFC-9112 is the current one, you're correct. But RFC-7230 is the "venerable" one and always will be.