Bug 1167612 - getting "200 OK" instead of "304 Not Modified" for many *.css, *.js and *.png files
Summary: getting "200 OK" instead of "304 Not Modified" for many *.css, *.js and *.png...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI
Version: 570
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
Assignee: Grant Gainey
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: sat570-postga
TreeView+ depends on / blocked
 
Reported: 2014-11-25 07:29 UTC by Jan Hutař
Modified: 2017-05-12 12:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-12 12:30:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jan Hutař 2014-11-25 07:29:43 UTC
Description of problem:
When browsing on Satellite interface, I'm getting "200 OK" instead of "304 Not Modified" for many *.css, *.js and *.png files (noticed in Firefox's web developer console and on the "Network" tab)


Version-Release number of selected component (if applicable):
Satellite-5.7.0-RHEL6-re20141119.0-x86_64


How reproducible:
always


Steps to Reproduce:
1. In WebUI navigate to "Systems" tab with Firefox's web developer console
   and on the "Network" tab
2. Go to "Errata" menu tab
3. Go back to "Systems" menu tab


Actual results:
For all requests made (except one) it reports "200 OK".


Expected results:
Fom Michael:

When you go from one page to the other browser do even not ask for .css
and .png files - it reuses locally cached content. On explicit reload
the answer should be "304 Not Modified".

I've checked this on my test instance to be sure :).

So "200 OK" on every tab seems to be  a problem (not sure where).

Comment 1 Stephen Herr 2014-11-25 15:18:13 UTC
Here is the response I see from my Spacewalk server, is this the same thing you're seeing?


----
GET bootstrap.js
	
200 OK (BFCache)
	
sherr-spacewalk.usersys.redhat.com
	
57.1 KB

The request was resolved directly from the cache, so we have no response from the server. See below for the cached response.
----

A 200 (Cache) is actually a better response than a 304 because 200 (Cache) doesn't bother sending any request up to the server so there is not time required at all. Your browser should be able to do a 200 (Cache) if the requested file has an "Expires" header. It may be that we're only recently correctly setting the header, and so requests that previously had to go up to the server only to get a 304 back are no longer necessary. If you're seeing a 200 (Cache) request then everything is working properly, however if you're seeing regular 200 requests that have a non-zero times for anything other than "Waiting" then that could indicate a problem.

Comment 3 Stephen Herr 2014-11-25 15:30:02 UTC
Hmm. I was useing Firebug to see that response. It seems that Firefox's built-in developer consol does not show 200 (cache) responses, so that almost certainly is not what you're seeing.

Comment 4 Stephen Herr 2014-11-25 15:39:12 UTC
On the other hand I cannot reproduce the behavior on the machine you're using, which tells me it's probably an issue with your browser and not with Satellite / Spacewalk. Have you by chance disabled Firefox's cache?

about:config (in url bar) -> network.http.use-cache

or possibly:

developer console -> settings (gear icon) -> Advanced Settings -> Disable Cache

Comment 5 Jan Hutař 2014-11-26 23:16:45 UTC
I have checked both settings and they both seem to be OK:

about:config (in url bar) -> network.http.use-cache - set to "true"

developer console -> settings (gear icon) -> Advanced Settings -> Disable Cache - not checked

Anyway I have compared with Satellite 5.6.0 and besides the page is twice as big, Firefox's Developer Tools -> Network (Ctrl + Shift + I) says:

 * on Sat 5.6.0: 4 of 30 requests cached
 * on sat 5.7.0: 1 of 24 requests cached

so this is not a regression (or not so big one).

I'm interested on why you can not reproduce. I have asked Michael Mraka and he has seen what I did.

Comment 8 Stephen Herr 2014-12-01 15:32:38 UTC
Hmm. Well as you point out the size of the css / javascript has doubled, so even if it's not really a regression that still makes this non-caching issue a lot more important on Sat 5.7 than it is on 5.6. In my opinion waiting > 20s for each page to load is too much.

However we still have the problem where I can't reproduce, so I still think that there must be something wrong with your browser. Have you tried a different browser? A different machine? Is anyone else able to reproduce the same problem?

Comment 9 Jan Hutař 2014-12-03 21:23:17 UTC
OK, just for a record: I have checked with Chrome and it says "200 OK (from cache)" exactly as Stephen noted back in comment #1. In this case, all is good and pardon me for the mess.

Comment 10 Grant Gainey 2017-05-12 12:30:30 UTC
Looks like this was supposed to be closed in 2014...


Note You need to log in before you can comment on or make changes to this bug.