if-modified-since question (protocol problem?)

[hug]

[originally posted in alt.www.webmaster, was suggested that this ng
could be a better place.]

I've updated my test server to handle if-modified-since. I've noticed
that the (old copies I run of) IE and Netscape seem never to send
if-modified-since. But the strange thing is that Opera sends
if-modified-since but when I reply with "HTTP/1.0 304 Not Modified" it
is not refreshing the screen from its cache, it is leaving the screen
blank.

I can only conclude that either I am not returning a correct protocol
sequence including "HTTP/1.0 304 Not Modified", or that the old Opera
I'm running contains a bug. I'm betting on the incorrect response in
my code.

Anybody have experience with handling if-modified-since themselves and
doing it properly?

--
http://www.ren-prod-inc.com/hug_soft...action=contact

[VK]

hug wrote:

[originally posted in alt.www.webmaster, was suggested that this ng
could be a better place.]

I've updated my test server to handle if-modified-since. I've noticed
that the (old copies I run of) IE and Netscape seem never to send
if-modified-since. But the strange thing is that Opera sends
if-modified-since but when I reply with "HTTP/1.0 304 Not Modified" it
is not refreshing the screen from its cache, it is leaving the screen
blank.

I can only conclude that either I am not returning a correct protocol
sequence including "HTTP/1.0 304 Not Modified", or that the old Opera
I'm running contains a bug. I'm betting on the incorrect response in
my code.

Anybody have experience with handling if-modified-since themselves and
doing it properly?

IMHO you are mixing two stages here: HTTP Request and HTTP Response

One side is making a request and to avoid unnecessary bandwight use may
set If-Modified-Since: <Date> *request* header.

Properly configured server has to check the <Date> and either respond
with content, or with 304 Not Modified *response* header.

It is not an additional feature of a web server, this is a core feature
of a normal HTTP/1.1 compliant web server.

If-Modified-Since (as well as If-None-Match, If-Range and
If-Unmodified-Since) has no relation to a UA <-> server communication
schema, it was made for server <-> server communications.

Still in XMLHttpRequest (Gecko) you can setRequestHeade r and if the web
server is not broken, it will either send data or 304.

I am not sure about the original IXMLHTTPRequest (Microsoft). The MSDN
seems silent, but it may be still implemented. Yours to try.

In any case no UA is allowed to set additional request headers by
itself, without user interaction. If Opera indeed does that(?), then it
has a broken HTTP/1.1 part.

If the request object was not interested in If-Modified-Since check,
then it also not interested in the check results (304 or something
else).

[Benjamin Niemann]

VK wrote:

hug wrote:

[originally posted in alt.www.webmaster, was suggested that this ng
could be a better place.]
Well, I'd suggest to send you back ;)
I've updated my test server to handle if-modified-since. I've noticed
that the (old copies I run of) IE and Netscape seem never to send
if-modified-since. But the strange thing is that Opera sends
if-modified-since but when I reply with "HTTP/1.0 304 Not Modified" it
is not refreshing the screen from its cache, it is leaving the screen
blank.

I can only conclude that either I am not returning a correct protocol
sequence including "HTTP/1.0 304 Not Modified", or that the old Opera
I'm running contains a bug. I'm betting on the incorrect response in
my code.

URL (if publicly accessible)? Or fetch the HTTP headers (e.g. Live HTTP
Headers extension for FF) and post 'em.
It is not an additional feature of a web server, this is a core feature
of a normal HTTP/1.1 compliant web server.
Sure, but if there's server-side code involved, than this 'feature' may has
to be (re-)implemented. The OP has not mentioned this explicitly, but
that's what I would guess.
If-Modified-Since (as well as If-None-Match, If-Range and
If-Unmodified-Since) has no relation to a UA <-> server communication
schema, it was made for server <-> server communications.
These header are to be used by any client that supports caching. Why should
UAs be excluded? Firefox sends If-* headers (for cacheable documents) and I
would be suprised, if this is not widely implemented in modern browsers.
In any case no UA is allowed to set additional request headers by
itself, without user interaction. If Opera indeed does that(?), then it
has a broken HTTP/1.1 part.

I've never set HTTP request headers manually for a browser. I set options
for my preferred languages (turned into Accept-Language header by the
browser) or the cache handling (which may result in sending If-* headers).

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/

[Alan J. Flavell]

On Sun, 7 May 2006, hug wrote:

[originally posted in alt.www.webmaster, was suggested that this ng
could be a better place.]
To be honest, I think they gave you poor advice. This appears to be a
feature of browser/server interaction which has nothing directly to do
with authoring HTML. I'd anticipate finding the experts on a web
servers group, or maybe on the CGI authoring group (in the latter
case, beware of the automoderation bot!).

But OK, let's try and make a start, despite that.
I've updated my test server to handle if-modified-since.
Decent servers do this out of the box, don't they?

What manner of server is this? Are you working on the server's own
code? Adding a module? Writing a CGI script?
I've noticed that the (old copies I run of) IE and Netscape seem
never to send if-modified-since.
Be specific! "Netscape"? 4 or less? 6 or more? They are totally
unrelated codebases.

The browsers that I use, most certainly do send if-modifed-since
requests. However, they have preferences/options which can adjust
their behaviour in this regard, and could be configured to never check
for updates.
But the strange thing is that Opera sends if-modified-since but when
I reply with "HTTP/1.0 304 Not Modified" it is not refreshing the
screen from its cache, it is leaving the screen blank.
You know, without having your actual server to play with over the
Internet, we'd be trying to help you with at least one hand tied
behind our backs.
I can only conclude that either I am not returning a correct protocol
sequence including "HTTP/1.0 304 Not Modified", or that the old Opera
I'm running contains a bug.
What's the problem with downloading a current one for comparison?
I've got an Opera 7, an Opera 8 and an Opera 9-preview installed
separately for testing. For example.
I'm betting on the incorrect response in my code.
We haven't seen any code yet.

While it's possible to instrument this kind of thing via a proxy, and
get the proxy to report the headers passing in each direction (you can
find this sort of thing documented in FAQs for CGI and/or Perl, for
example), it's sometimes easier to run Ethereal on the test platform
and just monitor the network traffic.

Ethereal nowadays does a very nice line in decoding the packet payload
- it usually doesn't need an expert to unpick the results. In fact I
was using it only a few days ago to study an HTTP transaction (and
elsewhere in its log I spotted a 304 response, but it wasn't what I
was looking for at the time, so I can't say much more).
Anybody have experience with handling if-modified-since themselves
and doing it properly?

Sort-of, but there's nothing in my test area at the moment that would
serve as an instant test of Opera. I'd suggest you need to show a bit
more of your working before you'd rate to get anything useful from the
group - BICBW.

good luck

[hug]

"VK" <sc**********@y ahoo.com> wrote:

IMHO you are mixing two stages here: HTTP Request and HTTP Response

One side is making a request and to avoid unnecessary bandwight use may
set If-Modified-Since: <Date> *request* header.

Properly configured server has to check the <Date> and either respond
with content, or with 304 Not Modified *response* header.

It is not an additional feature of a web server, this is a core feature
of a normal HTTP/1.1 compliant web server.

Thank you, but imho you don't know what you're talking about, as might
be expected of some guy who just has apache delivering up fixed pages.

If you will READ section 14.29 of RFC-2616, which is available here,
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html,
you will find the following:

"The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified. "

"The exact meaning of this header field depends on the implementation
of the origin server and the nature of the original resource. For
files, it may be just the file system last-modified time. For entities
with dynamically included parts, it may be the most recent of the set
of last-modify times for its component parts. For database gateways,
it may be the last-update time stamp of the record. For virtual
objects, it may be the last time the internal state changed. '

This seems to me to indicate that the last-modified time represents
the time the result page's contents changed. The server in question
is entirely made up of "dynamicall y included parts" and the time the
"internal state changed" is critical.

The entire point of the question is this. Opera sends an
if-modified-since and when it receives a not-modified it displays a
blank page, as if it had thrown away its cached copy. I think that I
need to find someone who actually knows his protocol-level http for
this one.

Thanks though, I appreciate that you tried.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

[hug]

Benjamin Niemann <pi**@odahoda.d e> wrote:

URL (if publicly accessible)? Or fetch the HTTP headers (e.g. Live HTTP
Headers extension for FF) and post 'em.

Apologies, but the code is not running on any publicly accessible
server because it isn't working, kind of a catch-22.

I've been doing my debugging with instrumentation added to the server.
I don't know how to capture the http stream otherwise. I've seen
postings here and there of captured headers but I don't know how they
were captured. What tool is used to look at the live stream? Thanks.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

[hug]

"Alan J. Flavell" <fl*****@physic s.gla.ac.uk> wrote:

On Sun, 7 May 2006, hug wrote: <snip>

I've updated my test server to handle if-modified-since.
Decent servers do this out of the box, don't they?

Only if your content consists entirely of fixed pages, then they use
the timestamp of the file. If the server is delivering content that
is entirely dynamic, the out-of-box stuff is doing nothing beneficial.
What manner of server is this? Are you working on the server's own
code? Adding a module? Writing a CGI script?
Database-driven PHP.

I've noticed that the (old copies I run of) IE and Netscape seem
never to send if-modified-since.

Be specific! "Netscape"? 4 or less? 6 or more? They are totally
unrelated codebases.

Doesn't matter, I'm really only concerned with Opera which is version
6.05
The browsers that I use, most certainly do send if-modifed-since
requests. However, they have preferences/options which can adjust
their behaviour in this regard, and could be configured to never check
for updates.
I've fiddled with Opera's settings but changing them doesn't seem
relevant to the behaviour in question.

But the strange thing is that Opera sends if-modified-since but when
I reply with "HTTP/1.0 304 Not Modified" it is not refreshing the
screen from its cache, it is leaving the screen blank.

You know, without having your actual server to play with over the
Internet, we'd be trying to help you with at least one hand tied
behind our backs.

I can only conclude that either I am not returning a correct protocol
sequence including "HTTP/1.0 304 Not Modified", or that the old Opera
I'm running contains a bug.

What's the problem with downloading a current one for comparison?
I've got an Opera 7, an Opera 8 and an Opera 9-preview installed
separately for testing. For example.

I was hoping to understand this before moving on to a newer version of
Opera. I know the Opera guys are good and always have been, but I've
been Microsoft'ed so many times that I've become extremely
conservative.

I'm betting on the incorrect response in my code.

We haven't seen any code yet.

We're talking about 3/4 meg of code here, I think that I won't post
it.
While it's possible to instrument this kind of thing via a proxy, and
get the proxy to report the headers passing in each direction (you can
find this sort of thing documented in FAQs for CGI and/or Perl, for
example), it's sometimes easier to run Ethereal on the test platform
and just monitor the network traffic.

Ethereal nowadays does a very nice line in decoding the packet payload
- it usually doesn't need an expert to unpick the results. In fact I
was using it only a few days ago to study an HTTP transaction (and
elsewhere in its log I spotted a 304 response, but it wasn't what I
was looking for at the time, so I can't say much more).

I'm not sure that I have the authorization to install it on the shared
server I'm using.

Anybody have experience with handling if-modified-since themselves
and doing it properly?

Sort-of, but there's nothing in my test area at the moment that would
serve as an instant test of Opera. I'd suggest you need to show a bit
more of your working before you'd rate to get anything useful from the
group - BICBW.

good luck

Thanks.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

[Neredbojias]

To further the education of mankind, "Alan J. Flavell"
<fl*****@physic s.gla.ac.uk> vouchsafed:

The browsers that I use, most certainly do send if-modifed-since
requests. However, they have preferences/options which can adjust
their behaviour in this regard, and could be configured to never check
for updates.

On a related but off-thread note referencing a previous thread you and I
participated in, Mozilla's version of "once per session" doesn't seem to
hack it. With this setting, neither Firefox nor SeaMonkey appear to detect
an altered page between sesssions, at least if the byte-count remains
constant. The only way I could get the new page to load reliably without
hitting "reload" is to use the "every page load" option. And, of course,
this isn't particularly satisfactory.

--
Neredbojias
Infinity has its limits.

[Alan J. Flavell]

On Mon, 8 May 2006, hug wrote:

"Alan J. Flavell" <fl*****@physic s.gla.ac.uk> wrote:

I'm betting on the incorrect response in my code.

We haven't seen any code yet. We're talking about 3/4 meg of code here,
If I was serious about investigating a problem of this kind, I'd have
started by boiling it down into a simple test-case without extraneous
detail.
Ethereal nowadays does a very nice line in decoding the packet
payload - it usually doesn't need an expert to unpick the results.

.... I'm not sure that I have the authorization to install it on the
shared server I'm using.

With respect, your situation in that regard wasn't clear enough from
the original posting. I half-thought you were running a test server
under your own control.

If at least the browser platform is under your control, how about
running Ethereal there? It should see the same traffic. That's
assuming it's available for your browser platform (the fact that
you're worrying about a version 6.05 of Opera leads me rather to
suspect it might be something unusual - you don't appear to have
mentioned the browser platform's OS yet?).

have fun

[Jack]

VK wrote:

If-Modified-Since (as well as If-None-Match, If-Range and
If-Unmodified-Since) has no relation to a UA <-> server communication
schema, it was made for server <-> server communications.
Huh???

This is simply incorrect. I'm not sure what kind of server <-> server
communication VK has in mind; perhaps he thinks If-Modified-Since is
intended for use by proxies or something. This isn't the case, although
it *may* be used by proxies. In fact it's intended for use by any kind
of client that can cache content. That includes UAs.

The same applies to any of the other cache-control headers.
In any case no UA is allowed to set additional request headers by
itself, without user interaction. If Opera indeed does that(?), then
it has a broken HTTP/1.1 part.
"Additional " to what? If-Modified-Since is a standard HTTP/1.1 request
header. Furthermore I'm not aware of any law that says a client can't
send whatever custom header it wants; the only regulations I'm aware of
specify what the server must do with headers it doesn't recognise
(ignore them).
If the request object was not interested in If-Modified-Since check,
then it also not interested in the check results (304 or something
else).

BEEP! Grokking failed, aborted. This reads as if it has something to do
with Java or ActiveX or whatever; but even then I can't parse it so it
makes sense. P'raps I haven't had enough coffee.
--
Jack.