Closed
Bug 14772
Opened 25 years ago
Closed 24 years ago
"Pragma: no-cache" header used incorrectly
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
VERIFIED
FIXED
M17
People
(Reporter: nigel, Assigned: ruslan)
References
Details
(Whiteboard: [nsbeta2-] ? days)
The version of Mozilla I just checked out of CVS always sends "Pragma: no-cache" if a proxy is configured, and never sends it otherwise. Whether or not Reload or <shift>Reload are pressed doesn't seem to make any difference. Mozilla should behave the same as Navigator 4.5/4.6 does: To request a URL not in the browser's cache: send a simple GET. To request verification of a URL that is in the browser's cache: send a GET with an "If-Modified-Since:" header. If the RELOAD button has been pressed: send a GET with an "If-Modified-Since:" header and a "Pragma: no-cache" header. If the RELOAD button has been pressed while the <SHIFT> key is held: send a GET with a "Pragma: no-cache" header (but no "If-Modified-Since:" header). This behavior should be the same whether or not an explicit proxy is configured. Why this is important: I am the HTTP/1.1 guy for the NetCache product at Network Appliance (http://www.netapp.com/products/netcache/). I'd like to help make sure that Mozilla plays well with our web cache appliance, which is found at many ISPs and web sites around the world. In particular, I'd like to point out a common browser misconception that caused problems for Netscape Navigator 4.0 (though it was fixed in 4.5), and is *still* a problem in MS Internet Explorer. The problem is the assumption that, unless a proxy server is explicitly configured in the browser, the browser is talking directly to a web server. And, therefore, it is only necessary to send a "no-cache" header with a refresh or reload request when a proxy is configured. This assumption is false because most NetCache customers intercept all TCP packets destined for port 80 at any IP address, and route them to a NetCache box running in transparent mode, which will always serve the request from its cache when possible, unless the HTTP headers in the request prevent this. If user wants to do an explicit end-to-end request by pressing RELOAD or <shift>RELOAD, the browser MUST add either a "Pragma: no-cache" header or (HTTP/1.1) a "Cache-Control: no-cache" header to the request to ensure that the request reaches the origin server, *regardless of whether or not an explicit proxy is configured*.
Reporter | ||
Comment 1•25 years ago
|
||
Added Brendan and Warren to CC list, at Brendan's request.
Yes I know about this bug. This was for testing some stuff that I was trying out. I will fix it tonite.
Comment 3•25 years ago
|
||
Fur made a suggestion for a slightly different cache-control header in the news://news.mozilla.org/netscape.public.mozilla.netlib group, so I'm cc'ing him on this bug. /be
Comment 4•25 years ago
|
||
Cut-and-paste'ing from my news post... For HTTP 1.1, I think it should be: If the RELOAD button has been pressed: send a GET with an "If-Modified-Since:" header and a ==> "Cache-Control:max-age=0" header. If the RELOAD button has been pressed while the <SHIFT> key is held: send a GET with an "If-Modified-Since:" header and a "Cache-Control:no-cache" header. By using 'max-age' rather than 'no-cache', end-to-end validation is performed without necessarily requiring that the whole entity body be retransmitted.
Comment 5•25 years ago
|
||
Any progress on this one? I'm at the end of a slow modem line, behind a proxy server. EVERYTHING reloads EVERY TIME and so apprunner is almost unusable!!!
Comment 6•25 years ago
|
||
Colin: There is no caching code in Mozilla yet and there probably won't be any for a month. So, for now, the complete network data will always need to be re-transferred across the 56K line on every fetch, regardless of whether the proxy refetches from the origin server or not.
Comment 7•25 years ago
|
||
I know there's no caching yet, and that real caching won't be around for a while yet. But I thought this bug report was asking if the code could be changed to NOT always blindly send "Pragma: no-cache" with each request.
Comment 8•25 years ago
|
||
I'm just saying that a bug fix is unlikely to help your particular problem since your speed is limited by your 56K line. Also, reporter of the bug filed it because we weren't sending pragma: no-cache in all the right cases, not because it was being sent too much.
Comment 9•25 years ago
|
||
Ah but it would help me! I have all my home systems networked together, and the one with the slow modem connection to the outside world (not even 56K) also acts as a proxy server for everyone else. So, what usually happens is that the first time I access a page, its real slow while it downloads via the slow modem. But subsequent accesses are much faster because the proxy server system has cached it and so a retransmit is not required. But with apprunner, its slow every time. I assume because apprunner is sending the no-cache pragma and so my proxy server is forced to go fetch the page every time. I sure many people must be in the same position as me (though most have better network connections (that's what I get for living in the boonies))
Updated•25 years ago
|
Target Milestone: M11
Comment 10•25 years ago
|
||
Gagan -- no-cache should be simple to take out, right?
Comment 11•25 years ago
|
||
There needs to be a couple of bits added to the channel's LoadAttributes field, e.g. LOAD_VALIDATE and LOAD_FORCE_REFETCH, which would correspond to pressing Reload and Shift-Reload, respectively. The choice of headers would be based on these flags.
Comment 12•25 years ago
|
||
This is weird... I thought I had removed it... but I guess I must not have checked that in. I will check it in right away. Sorry for the delay.
Comment 13•25 years ago
|
||
Fix checked in. Repull mozilla/netwerk/protocol/http/src/nsHTTPRequest.cpp
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 14•25 years ago
|
||
This bug should remain open until it is fully fixed. The partial fix that closed it only removed the "Pragma: no-cache" header from proxy requests. The main problem described in the original description still remains.
Comment 15•25 years ago
|
||
Clearing Fixed resolution due to reopen.
Updated•25 years ago
|
Target Milestone: M11 → M12
Comment 16•25 years ago
|
||
->m12
Comment 17•25 years ago
|
||
Moving Assignee from gagan to warren since he is away.
Updated•25 years ago
|
Assignee: warren → fur
Comment 18•25 years ago
|
||
Scott, Can you own this one? Thanks.
Comment 19•25 years ago
|
||
Moving what's not done for M12 to M13.
Updated•25 years ago
|
Comment 20•25 years ago
|
||
I made the changes to send different headers based on the settings of the load attributes. FORCE_RELOAD: Pragma:no-cache cache-control:no-cache FORCE_VALIDATE Pragma:no-cache Cache-Control:max-age=0 If-Modified-Since:xxxxxx Now, we just have to wait until someone hooks up the UI to the load attribute flags and this bug can be marked FIXED. See bug #21137.
Comment 21•25 years ago
|
||
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Comment 22•25 years ago
|
||
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
Updated•25 years ago
|
Component: Networking → Networking: Cache
Target Milestone: M13 → M14
Comment 23•25 years ago
|
||
*** Bug 6627 has been marked as a duplicate of this bug. ***
Comment 25•25 years ago
|
||
pdt - what is the user impact here?
Updated•25 years ago
|
Whiteboard: [pdt-]
Updated•25 years ago
|
Summary: [4.xP] "Pragma: no-cache" header used incorrectly → "Pragma: no-cache" header used incorrectly
Comment 26•25 years ago
|
||
*** Bug 20201 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 27•25 years ago
|
||
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Comment 29•24 years ago
|
||
Putting on [nsbeta2-] radar. We need a clear picture on what must be done. Putting on nsbeta2 radar to review later.
Keywords: nsbeta3
Whiteboard: [pdt-] ? days → [nsbeta2-][pdt-] ? days
Assignee | ||
Comment 30•24 years ago
|
||
Hey - we know what must be done. It depends on 21137 to get fixed. It has to go into beta2 IMHO.
Comment 31•24 years ago
|
||
Removing nsbeta2- per Ruslan's comment.
Keywords: beta1
Whiteboard: [nsbeta2-][pdt-] ? days → ? days
Assignee | ||
Comment 33•24 years ago
|
||
Ok. Looking at the code it looks like I've fixed it by accident a while back :-) Please reopen the bug if you find any problems :-)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•