Closed Bug 14772 Opened 25 years ago Closed 24 years ago

"Pragma: no-cache" header used incorrectly

Categories

(Core :: Networking: Cache, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

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*.
Added Brendan and Warren to CC list, at Brendan's request.
Status: NEW → ASSIGNED
Yes I know about this bug. This was for testing some stuff that I was trying out. I will fix it tonite.
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
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.
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!!!
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.
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.
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.
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))
Target Milestone: M11
Gagan -- no-cache should be simple to take out, right?
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked in. Repull mozilla/netwerk/protocol/http/src/nsHTTPRequest.cpp
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Clearing Fixed resolution due to reopen.
Target Milestone: M11 → M12
->m12
Moving Assignee from gagan to warren since he is away.
Assignee: warren → fur
Scott, Can you own this one? Thanks.
Moving what's not done for M12 to M13.
Blocks: 14050
Depends on: 21137
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.
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
Component: Networking → Networking: Cache
Target Milestone: M13 → M14
*** Bug 6627 has been marked as a duplicate of this bug. ***
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
Keywords: beta1
pdt - what is the user impact here?
Whiteboard: [pdt-]
Summary: [4.xP] "Pragma: no-cache" header used incorrectly → "Pragma: no-cache" header used incorrectly
*** Bug 20201 has been marked as a duplicate of this bug. ***
Keywords: beta2
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Whiteboard: [pdt-] → [pdt-] ? days
Keywords: nsbeta2
-> ruslan
Assignee: gordon → ruslan
Keywords: beta2
Status: NEW → ASSIGNED
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
Hey - we know what must be done. It depends on 21137 to get fixed. It has to go into beta2 IMHO.
Removing nsbeta2- per Ruslan's comment.
Keywords: beta1
Whiteboard: [nsbeta2-][pdt-] ? days → ? days
Putting on nsbeta2- radar.
Whiteboard: ? days → [nsbeta2-] ? days
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 ago24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.