It is up to the browser but they behave in similar ways.
F5 usually updates the page only if it is modified. Modern browsers sends Cache-Control: max-age=0
to tell any cache the maximum amount of time a resource is considered fresh, relative to the time of the request.
CTRL-F5 is used to force an update, disregarding any cache. Modern browsers sends Cache-Control: no-cache
and Pragma: No-cache
If I remember correctly it was Netscape which was the first browser to add support for cache-control by adding Pragma: No-cache
when you pressed CTRL-F5.
┌───────────┬──────────────┬─────┬─────────────────┬──────────────────────────────┐
│ Version 4 │ F5 │ R │ CLICK │ Legend: │
│2021 MAY 19├──┬──┬──┬──┬──┼──┬──┼──┬──┬──┬──┬──┬──┤ C = Cache-Control: no-cache │
│ │ │S │C │A │A │C │C │ │S │C │A │A │C │ I = If-Modified-Since │
│ │ │H │T │L │L │T │T │ │H │T │L │L │T │ M = Cache-Control: max-age=0 │
│ │ │I │R │T │T │R │R │ │I │R │T │T │R │ N = Not tested │
│ │ │F │L │ │G │L │L │ │F │L │ │G │L │ P = Pragma: No-cache │
│ │ │T │ │ │R │ │+ │ │T │ │ │R │+ │ - = ignored │
│ │ │ │ │ │ │ │S │ │ │ │ │ │S │ │
│ │ │ │ │ │ │ │H │ │ │ │ │ │H │ With 'CLICK' I refer to a │
│ │ │ │ │ │ │ │I │ │ │ │ │ │I │ mouse click on the browsers │
│ │ │ │ │ │ │ │F │ │ │ │ │ │F │ refresh-icon. │
│ │ │ │ │ │ │ │T │ │ │ │ │ │T │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ 1: Version 3.0.6 sends I │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ and C, but 3.1.6 opens │
│Brave 1.24 │M │CP│CP│- │- │M │CP│M │CP│CP│M │CP│CP│ the page in a new tab, │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ making a normal request │
│Chrome 1 │MI│MI│MI│- │- │MI│- │MI│MI│MI│MI│MI│N │ with only I. │
│Chrome 6 │MI│CP│CP│- │- │MI│CP│MI│CP│CP│MI│- │N │ 2: Version 10.62 does │
│Chrome 90 │M │CP│CP│- │- │M │CP│M │CP│CP│M │CP│CP│ nothing. 9.61 might do C │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ unless it was a typo in │
│Edge 90 │M │CP│CP│- │- │M │CP│M │CP│CP│M │CP│CP│ my old table. │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ 3: Opens the currernt tab in │
│Firefox 3.x│MI│- │CP│- │- │MI│CP│MI│CP│1 │M │MI│N │ a new tab, but does not │
│Firefox 89 │M │- │CP│- │M │M │CP│M │CP│3 │M │M │3 │ refresh the page if it is │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ cached in the browser. │
│MSIE 8, 7 │I │- │C │- │I │I │ │I │I │C │I │I │N │ │
├───────────┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┼──┤ │
│Opera 10, 9│C │- │- │2 │- │C │- │C │C │C │C │- │N │ │
│Opera 76 │M │CP│CP│- │- │M │- │M │CP│CP│M │CP│CP│ │
├───────────┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──────────────────────────────┤
│ https://stackoverflow.com/a/385491/36866 │
└─────────────────────────────────────────────────────────────────────────────────┘
Note about Chrome 6.0.472: If you do a forced reload (like CTRL-F5) it behaves like the url is internally marked to always do a forced reload. The flag is cleared if you go to the address bar and press enter.
According to RFC 1341 (made obsolete by RFC 2045):
A Content-Transfer-Encoding header field, which can be used to
specify an auxiliary encoding that was applied to the data in order to
allow it to pass through mail transport mechanisms which may have
data or character set limitations.
and later:
Many Content-Types which could usefully be transported via email
are represented, in their "natural" format, as 8-bit character or
binary data. Such data cannot be transmitted over some transport
protocols. For example, RFC 821 restricts mail messages to 7-bit
US-ASCII data with 1000 character lines.
It is necessary, therefore, to define a standard mechanism for
re-encoding such data into a 7-bit short-line format. (...) The
Content-Transfer-Encoding field is used to indicate the type of
transformation that has been used in order to represent the body
in an acceptable manner for transport.
Since you have a webservice, which has nothing in common with emails, you shouldn't use this header.
You can use Content-Encoding
header which indicates that transferred data has been compressed (gzip value).
I think that in your case
Content-Type: application/pdf
is enough. Additionally, you can set Content-Length
header, but in my opinion, if you are building webservice (it's not http server / proxy server) Content-Type
is enough. Please bear in mind that some specific headers (e.g. Transfer-Encoding
) if not used appropriately, may cause unexpected communication issues, so if you are not 100% sure about usage of some header - if you really need it or not - just don't use it.
Best Answer
Why should there be any overhead? HTTP does not usually do things like base64 encoding (you may be thinking of e-mail, which mostly uses different 7bit encodings creating a lot of overhead). The
content-type
header has little to nothing to do with your data encoding, but with how clients try to handle it. with octet-stream the clients will always prompt for a download, even when the file is text/plain from its content.