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
You need to log in
before you can comment on or make changes to this bug.
Description
•