Closed Bug 14772 Opened 25 years ago Closed 24 years ago

"Pragma: no-cache" header used incorrectly

Categories

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

Product:
Core
Component:
Networking: Cache
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
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 ago → 24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.