Re: if-modified-since question (protocol problem?)

On 13/05/2006 08:45, VK wrote:

Michael Winter wrote:

[VK:]
1. <http://www.nskom.com/external/tmp/http/204.cgi> This script
randomly generates new page with server timestamp or sends 204 No
Content.

2. Hit Refresh several times to get at least 2 or 3 page updates.


3. Hit Back bitton and see where are you going.

[snip]

No offence, but it's already the second exclusivity demonstrated by
your test system (counting the first the application/xhtml+xml
handling, see the "DTD in browsers" thread).

You don't need to consider the state of my system to understand that the precise process you describe is impossible. A little common sense should be enough.

A refresh action using F5 (with or without modifiers), an equivalent key combination, or the Refresh GUI control, is not navigation in the sense of activating a link, loading a bookmark, or typing a URL. These actions take the user somewhere, so the concept of going backwards or forwards makes sense. A refresh updates the current document: there is no movement. That said, requesting an identical URL in Firefox and IE is considered to be the same as a refresh so your 'test', as it stands, cannot be used with them to evaluate the behaviour of the Back and Forward buttons.

Still, even when loading your 'test' from a bookmark or re-entering the URL, subsequent use of the Back and Forward buttons still doesn't result in additional network traffic.

[snip]

By vigoriously excluding not proper testing/description from your
side, it is needed to assume that you are sitting behind some really
=~ overly smart proxy that does all kind of runtime adjustments with request/response.

Perhaps you'd care for a brief description, then? You are welcome to state your method.

First, software you might consider relevant:

- Windows XP Professional (with SP2)
- Opera 8.54 (build 7730)
Relevant History settings:
Memory cache: Automatic
Disk cache: 10MB
Check ...: Every 5 Hours
No proxies configured.
- Ethereal 0.99.0

In each case, the cache is emptied before beginning, and a new tab is created. As I described previously, refreshing will not enable the navigation controls so the URL:

<http://www.nskom.com/external/tmp/http/204.cgi>

will be pasted into the location bar, instead.

A total of five requests will be made in each run, with Ethereal capturing all inbound and outbound HTTP traffic over my WAN interface. However, for simplicity, I'll only include the request and status lines. After the requests have been made, I'll step back through each to the first using the Back button, then forward again to the last.

The first run using the initial settings:

1 GET /external/tmp/http/204.cgi HTTP/1.1
HTTP/1.1 200 OK

There was no further traffic.

As I stated previously, your 'test' doesn't send any freshness information, therefore Opera reverts to the 'Check ...' options to determine whether to revalidate a cached resource. As each option was set to an interval of five hours during that run, the next four requests were served from the cache.

Clearly, these settings don't tell us much. One could argue that there was no traffic from the navigation controls because the requests you expected to see were served from the cache, too. Therefore, for the second run, all three 'Check ...' options will be set to 'Always' to force revalidation (though really, only 'Check documents' needs to be changed).

1 GET /external/tmp/http/204.cgi HTTP/1.1
HTTP/1.1 204 No Content
2 GET /external/tmp/http/204.cgi HTTP/1.1
HTTP/1.1 204 No Content
3 GET /external/tmp/http/204.cgi HTTP/1.1
HTTP/1.1 200 OK
4 GET /external/tmp/http/204.cgi HTTP/1.1
If-Modified-Since: Sat, 13 May 2006 12:15:03 GMT
HTTP/1.1 200 OK
5 GET /external/tmp/http/204.cgi HTTP/1.1
If-Modified-Since: Sat, 13 May 2006 12:15:17 GMT
HTTP/1.1 200 OK

There was no further traffic.

In this run, the cache was not automatically used to serve later requests: once a cacheable entity was available, Opera sent conditional requests.

With the cache ignored (in the absence of a 304 response), and following one of your earlier statements:

Say the same Opera (which was in OP) simply doesn't care of
your headers for < > navigation and doesn'r read them. It goes
by "Expire in X days" in UA preferences.
-- 1147263656.342480.207750@xxxxxxxxxxxxxxxxxxxxxxxxxxxx

one must conclude that you'd expect four more requests as the preferences call for revalidation, but they didn't occur.

The source code of the testcase (thus all headers it really sends)
was already posted. It may be interesting to check all headers you
/really/ get: via an ajaxoid or some more sophisticated network tool.

Not that it was necessary, but now I have and the evidence points to a rather obvious (and predictable) result.

You cannot blame some mythical proxy server (outbound traffic is monitored before that point), and there are no in-browser settings that can modify its behaviour in such a fundamental way (and I haven't edited any configuration files).

From my side I only can confirm that all headers are going "as it is"
back and forth. If confirmer the same for you, then the situation
must be further narrowed to OS/browser installation specifics.

Or, you might just want to consider that you're wrong. You've provided no evidence that I am, and I would have hoped that another regular would have jumped in by now to correct me if I was.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
.