Author Topic: Response Headers  (Read 3784 times)

hpguru

  • Sr. Member
  • ****
  • Posts: 257
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://lightning.prohosting.com/~hpguru/
    • Email
Facing each other,
a thousand miles apart.

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
Response Headers
« Reply #1 on: May 28, 2002, 12:34:16 PM »
That's really useful! Thanks

Note: I couldn't go there with Opera as User-Agent.
I usually pretend to use Opera instead of IE6 since many pages are much less aggressive then.

I was talking with JD5000 about cache controlling headers, and some things came up that i really would like to know:

Has killing CACHE-CONTROL the same effect as setting it to public?
If i change above, do i still have to kill PRAGMA (no-cache)?
Is it useful to kill ETAG if i want to cache everything?

The only way to surely get the complete fresh page on reload seems to be killing IF-MODIFIED-SINCE (CTRL-F5 won't always work in IE).
I guess i undermine the efficiency of my cache by doing so?
I'm using a local proxy for caching that does a much better job than IE and is able to cache everything.

<edit>
I forgot yet another one: EXPIRES
Generally speaking, which kills are superfluous?
So many questions
</edit>

regards, sidki

Edited by - sidki3003 on 28 May 2002  14:56:51
 

pooms

  • Jr. Member
  • **
  • Posts: 75
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • Email
Response Headers
« Reply #2 on: May 28, 2002, 04:29:36 PM »
Perhaps the HTTP RFC describes what you want to know:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14

 
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
Response Headers
« Reply #3 on: May 28, 2002, 04:39:10 PM »
Definitely a keeper, thank you

 
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
Response Headers
« Reply #4 on: May 29, 2002, 01:48:07 PM »
This is a repost of a message that got lost during ISP change.

Here is what i've got so far through the above RFC link and by looking at Homeric's config.

for caching as much as possible (header value and replacement empty):

Cache-Control: (in) (same as setting the replacement to "pub")
Pragma: (in) (add "no-cache" to the header value to play safe)
ETag: (in)
Expires: (in)
Vary: (in)

for debugging only (header value and replacement empty):

Pragma: (out) disables browser refresh
If-Modified-Since: (out) forces a fresh page, cache is ignored
Last-Modified: (in) forces a fresh page, cache is ignored

None seems to be redundant (correct me if i'm wrong).


 
 

xartica

  • Newbie
  • *
  • Posts: 38
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • Email
Response Headers
« Reply #5 on: May 31, 2002, 03:05:37 AM »
quote:

Here is what i've got so far through the above RFC link and by looking at Homeric's config.

for caching as much as possible (header value and replacement empty):

Cache-Control: (in) (same as setting the replacement to "pub")
Pragma: (in) (add "no-cache" to the header value to play safe)
ETag: (in)
Expires: (in)
Vary: (in)



Toward facilitating caching, I wouldn't trust "public" to be a cache-friendly
value ~~ instead, just match "*" and no replacement line.


I don't think you're confused by this, but for the benefit of other readers...
The _NAMES_ of Prox header filters often cause confusion, because they're
named to reflect the EFFECT that activating the filter will have.
For instance, the filter named "Cache-Control: always cache (in)" indicates that if you always want your pages cached (to increase page load speed) you should enable this filter ~~ and that the appropriate place to do so is "IN" (the $IHDR).
-=-
This approach (to explaining/understanding) the filters also ignores the fact that other headers, and their content, affect caching.


Instead of looking at the "filter name", consider what each header (type) does, the possible valid content "values" for that header type, and what effect each value will have, if present.

FWIW, here's what I use for the Cache-Control $IHDR:

In = TRUE
Out = FALSE
URL = "(^$LST(DisallowCaching))"
Key = "Cache-Control: strip this header to facilitate caching (in)"
Match = "*"

List.DisallowCaching contains the few sites like eBay and eTrade
whose pages I would NOT want to be cached, e.g.:
([^/]++.|)ebay.com/*
([^/]++.|)half.com/*
([^/]++.|)flaaten.dk/*


--------------------------------------------
FWIW, I suspect that the most common reason sites
configure their webserver to include the Cache-Control header
and to set it to "no-cache"... is to drive up "pagehits" and
banner display counts.
--------------------------------------------


quote:

for debugging only (header value and replacement empty):

Pragma: (out) disables browser refresh
If-Modified-Since: (out) forces a fresh page, cache is ignored
Last-Modified: (in) forces a fresh page, cache is ignored

None seems to be redundant (correct me if i'm wrong).




I don't disturb the "If_Modified-Since" header. Seems to me that the effect of stripping the tag, if it exists, counters the webbrowser's ability/CHOICE to use cached copy of page.

Above, in this discussion thread, I read:
"The only way to surely get the complete fresh page on reload seems to be killing IF-MODIFIED-SINCE (CTRL-F5 won't always work in IE)."

MSIE uses the If-Modified-Since and Last-Modified headers in tandem
(you'd have to strip both of them to have an effect)
(if either is present, MSIE will act on them)
and I'm struggling to understand why/when it would EVER be desirable to disturb the headers, if they are present.

??? Ctrl+F5 ?
Really? I thought it was just F5 (to definitively pull down a fresh copy)
Anyhow, maybe you're only stripping one of the two (tandem) headers.

Regardless of MSIE, I've noticed in the Prox log window "Browser Refresh Detected". How does is know? Where does PROX get/find/store the info?

 
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
Response Headers
« Reply #6 on: May 31, 2002, 03:50:58 AM »
Hi xartica,

Glad to get a response on this

Cache-Control:public -> good to know that. Thanks!

CTRL-F5 -> with F5 you still get "304 Not Modified", meaning you'll get the old gifs etc.
CTRL-F5 is an undocumented keystroke to reload everything.

quote:

I'm struggling to understand why/when it would EVER be desirable to disturb the headers, if they are present.



If you are testing different configs you have to make sure getting a fresh copy.
You can empty the cache or, more easy, kill these headers.

quote:

Regardless of MSIE, I've noticed in the Prox log window "Browser Refresh Detected". How does is know? Where does PROX get/find/store the info?



Isn't it just proxo detecting an outgoing pragma:no-cache?

 
 

TEggHead

  • Jr. Member
  • **
  • Posts: 93
    • ICQ Messenger - 21893433
    • AOL Instant Messenger -
    • Yahoo Instant Messenger - eljarec
    • View Profile
    • Email
Response Headers
« Reply #7 on: June 05, 2002, 11:44:31 PM »
Hi SidKi,

quote:
I'm using a local proxy for caching that does a much better job than IE and is able to cache everything.


SmartCache?

There's a possible pitfall here with respect to Cache-Control header.
I also have an external caching proxy running and on another machine at that, saves a lot of bandwith on a homelan. AAR it is located between Proxo and the Internet in my proxychain.

The effect however is that modifying the incoming headers now only has effect on the IE cache, but your caching proxy would still have seen the original header...negating any advantages you thought you had...as the caching proxy will still retrieve it in this case

I'm ever so slowly thinking of ripping apart my config in two parts, and put a instance of Prox between the cache and the net with just header filters...webfilters are highly adapted to personal use, so not suited for central use...this type of headerfilters however is...but it is another proxy in the chain...it is already stretching with Prox, the Cache and the NAT router and packetfilter...

BTW. CTRL-F5 isn't documented because the CTRL -action in windows has a default meaning of taking the command it is used with, to a next level, meaning the command still does the same but either with an added extra or a bit quicker.

For instance, CTRL <click refresh> works too, but ctrl-left click selects everything from start upto where you clicked, ctrl-maximize switches to kioskmode nomatter if IE or regular explorer, etc, lot's of commands affected like this...always with a sort of speedup or power quirk...
another one if you have many windows open, keep CTRL down and press each taskbarbutton, after the last you want closed, release CTRL and rightclick one of the pressed taskbar buttons, choose close and they all close as one.

Lots of little surprises

Edited by - TEggHead on 06 Jun 2002  00:53:56
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
Response Headers
« Reply #8 on: June 06, 2002, 12:43:08 AM »
Hi JarC,

SmartCache is indeed the best one regarding caching, but i noticed this persistent connection problem discussed in depth at Y!G (i might be wrong). So i'm using ProxyPlus.
Since i'm running a single machine, my chain is browser -> ProxyPlus -> Proxo -> the world.
That should be ok.

CTRL... Wow!

regards, sidki