By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,919 Members | 1,074 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,919 IT Pros & Developers. It's quick & easy.

if-modified-since question (protocol problem?)

P: n/a
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
May 7 '06 #1
Share this Question
Share on Google+
102 Replies


P: n/a
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 setRequestHeader 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).

May 8 '06 #2

P: n/a
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/
May 8 '06 #3

P: n/a
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
May 8 '06 #4

P: n/a
hug
"VK" <sc**********@yahoo.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 "dynamically 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
May 10 '06 #5

P: n/a
hug
Benjamin Niemann <pi**@odahoda.de> 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
May 10 '06 #6

P: n/a
hug
"Alan J. Flavell" <fl*****@physics.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
May 10 '06 #7

P: n/a
To further the education of mankind, "Alan J. Flavell"
<fl*****@physics.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.
May 10 '06 #8

P: n/a
On Mon, 8 May 2006, hug wrote:
"Alan J. Flavell" <fl*****@physics.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
May 10 '06 #9

P: n/a
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.
May 10 '06 #10

P: n/a
VK

hug wrote:
Thank you, but imho you don't know what you're talking about
actually I do, but you are entitled for an alternate opinion.
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. "
You asked about If-Modified-Since *request* header. What in the name
Last-Modified *response* header has to do with it?
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.
How about Google?
<http://list.opera.com/pipermail/opera-linux/2002-September/003622.html>
Thanks though, I appreciate that you tried.


You are welcome. If for sport you *have* to support Opera 6.x (it is
Opera 8.5x for the last year) you may be more lucky with 204 No content
header.

Simply check the data source server-side and take a server-side
decision if it's the same or not. Obviously neither UA nor HTTP server
may know if www.foo.bar/data.php contains new data or not, only you do.
If the data is the same, simply throw back
Status: 204 No Content\n\n

The browser will stay on the current page and its cache will not be
changed.

Also if the only browser you are interested in is Opera, you may get
more luck in their support center: <http://www.opera.com/support/>

May 10 '06 #11

P: n/a
hug
"VK" <sc**********@yahoo.com> wrote:
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. "


You asked about If-Modified-Since *request* header. What in the name
Last-Modified *response* header has to do with it?


You snipped this:

"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."

Apparently the concepts that (a) last-modified time may depend on data
residing on the server, (b) if-modified-since is an attempt by the
client to avoid refreshing locally using stale data, and (c) if the
actual page content has changed since the time specified in the
if-modified-since sent by the client the server may either regenerate
the page or send a not-modified header in a response with no body, are
totally beyond you.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #12

P: n/a
hug
"VK" <sc**********@yahoo.com> wrote:
How about Google?
<http://list.opera.com/pipermail/opera-linux/2002-September/003622.html>


Interesting reading, though not really describing the particular
problem at hand. I read it a few days ago but didn't notice this
part:

* Some Webserver cannot determine correctly, if a file which is to
* be served has dynamic content (apache2 / PHP4 problem). This
* causes the webserver to answer with "302 - not modified", although
* the content (which is dynamic) has changed.

There is no "302 - not modified", the 302 code indicates "Found".
Thanks though, I appreciate that you tried.


You are welcome. If for sport you *have* to support Opera 6.x (it is
Opera 8.5x for the last year) you may be more lucky with 204 No content
header.

Simply check the data source server-side and take a server-side
decision if it's the same or not. Obviously neither UA nor HTTP server
may know if www.foo.bar/data.php contains new data or not, only you do.
If the data is the same, simply throw back
Status: 204 No Content\n\n


Interesting.

10.3.5 -- 304 "304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. "

14.25 -- "If-Modified-Since
The If-Modified-Since request-header field is used with a method to
make it conditional: if the requested variant has not been modified
since the time specified in this field, an entity will not be returned
from the server; instead, a 304 (not modified) response will be
returned without any message-body."

To me, these clearly indicate that a GET with an If-Modified-Since
should receive a '304 Not Modified' response. On the other hand,

"10.2.5 204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent..."

I don't quite understand the intended protocol sequence where this
response field is expected be used -- I see nothing that requires a
conditional request in order to include this response field. If the
server has "fulfilled the request" that sounds as if it would normally
be used in response to a POST in lieu of the server's generating an
"operation has been performed" page. This sentence seems to confirm
that, "This response is primarily intended to allow input for actions
to take place without causing a change to the user agent's active
document view,..."

Using it as the response to a conditional request instead of
not-modified seems wrong, though the spec does say SHOULD rather than
MUST. I suppose that one could consider the not-modified header to
have "fulfilled the request" and include this header field in
addition.

I'll give that a try and see what can be learned. Thank you.

This seems within an inch of being entirely unrelated to
"authoring.html" are you aware of a more appropriate venue for http
discussions?

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #13

P: n/a
On Tue, 9 May 2006, hug wrote:
"VK" <sc**********@yahoo.com> wrote:
I'd have to propose treating anything you get from that contributor
with a fairly hefty pinch of salt...
* Some Webserver cannot determine correctly, if a file which is to
* be served has dynamic content (apache2 / PHP4 problem). This
* causes the webserver to answer with "302 - not modified", although
* the content (which is dynamic) has changed.

There is no "302 - not modified", the 302 code indicates "Found".
Indeed, and would include a Location: header telling the client where
to go next.
Simply check the data source server-side and take a server-side
decision if it's the same or not. Obviously neither UA nor HTTP server
may know if www.foo.bar/data.php contains new data or not, only you do.
If the data is the same, simply throw back
Status: 204 No Content\n\n


I suspect this is a red-herring. 204 is rarely used in practice,
whereas if-modified requests with 304 response are everyday routine
for a wide range of browsers.

While I'm not saying I've seen the kind of wild anomalies recently in
204 responses that I used to see in earlier years, I really wouldn't
try it unless it was absolutely clear that it was the right answer,
which it surely isn't here.
Interesting.

10.3.5 -- 304 "304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. "

14.25 -- "If-Modified-Since
The If-Modified-Since request-header field is used with a method to
make it conditional: if the requested variant has not been modified
since the time specified in this field, an entity will not be returned
from the server; instead, a 304 (not modified) response will be
returned without any message-body."

To me, these clearly indicate that a GET with an If-Modified-Since
should receive a '304 Not Modified' response.
Or a 200 response, according to circumstances, indeed.
"10.2.5 204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent..."

I don't quite understand the intended protocol sequence where this
response field is expected be used --
In the situations that I've used 204, it's been a response to what, in
HTML terms, was a form submission, but was presented to the user as a
control panel in their browser window (for controlling something which
was happening outside of the browser). The user would be aware that
their control-button pushing had been effected, when they saw the
results. The control panel stayed on the browser, unchanged.
I see nothing that requires a conditional request in order to
include this response field.
Correct.
"This response is primarily intended to allow input for actions
to take place without causing a change to the user agent's active
document view,..."
It's usually best confined to situations where the user will get some
independent confirmation out-of-band that the request has been
successful. Otherwise, they're liable to keep repeating the command
in the belief that nothing has happened yet.
Using it as the response to a conditional request instead of
not-modified seems wrong,


I think so too.

May 10 '06 #14

P: n/a
Alan J. Flavell wrote:
"This response is primarily intended to allow input for actions to
take place without causing a change to the user agent's active
document view,..."


It's usually best confined to situations where the user will get some
independent confirmation out-of-band that the request has been
successful. Otherwise, they're liable to keep repeating the command
in the belief that nothing has happened yet.
Using it as the response to a conditional request instead of
not-modified seems wrong,


I think so too.


As I read it, the 204 specifically tells the browser not to change the
document view; the 304 says that the document content on the server is
not different from the client's copy.

So supposing the document view is currently http://example.com/foo, and
http://example.com/bar is requested, the two responses would have quite
different results. In the case of a 304, the UA would display the cached
copy of bar, whereas a 204 response should cause it to continue
displaying foo.

--
Jack.
May 10 '06 #15

P: n/a
hug
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> wrote:
On Tue, 9 May 2006, hug wrote:
"VK" <sc**********@yahoo.com> wrote:


I'd have to propose treating anything you get from that contributor
with a fairly hefty pinch of salt...


I have a high-sodium diet.
* Some Webserver cannot determine correctly, if a file which is to
* be served has dynamic content (apache2 / PHP4 problem). This
* causes the webserver to answer with "302 - not modified", although
* the content (which is dynamic) has changed.

There is no "302 - not modified", the 302 code indicates "Found".


Indeed, and would include a Location: header telling the client where
to go next.
>Simply check the data source server-side and take a server-side
>decision if it's the same or not. Obviously neither UA nor HTTP server
>may know if www.foo.bar/data.php contains new data or not, only you do.
>If the data is the same, simply throw back
> Status: 204 No Content\n\n


I suspect this is a red-herring. 204 is rarely used in practice,
whereas if-modified requests with 304 response are everyday routine
for a wide range of browsers.

While I'm not saying I've seen the kind of wild anomalies recently in
204 responses that I used to see in earlier years, I really wouldn't
try it unless it was absolutely clear that it was the right answer,
which it surely isn't here.
Interesting.

10.3.5 -- 304 "304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. "

14.25 -- "If-Modified-Since
The If-Modified-Since request-header field is used with a method to
make it conditional: if the requested variant has not been modified
since the time specified in this field, an entity will not be returned
from the server; instead, a 304 (not modified) response will be
returned without any message-body."

To me, these clearly indicate that a GET with an If-Modified-Since
should receive a '304 Not Modified' response.


Or a 200 response, according to circumstances, indeed.
"10.2.5 204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent..."

I don't quite understand the intended protocol sequence where this
response field is expected be used --


In the situations that I've used 204, it's been a response to what, in
HTML terms, was a form submission, but was presented to the user as a
control panel in their browser window (for controlling something which
was happening outside of the browser). The user would be aware that
their control-button pushing had been effected, when they saw the
results. The control panel stayed on the browser, unchanged.
I see nothing that requires a conditional request in order to
include this response field.


Correct.
"This response is primarily intended to allow input for actions
to take place without causing a change to the user agent's active
document view,..."


It's usually best confined to situations where the user will get some
independent confirmation out-of-band that the request has been
successful. Otherwise, they're liable to keep repeating the command
in the belief that nothing has happened yet.
Using it as the response to a conditional request instead of
not-modified seems wrong,


I think so too.


I tried the "no content" header, in -addition- to the usual response
headers, and it made no difference. I will not even bother trying it
-without- the headers that the spec calls for.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #16

P: n/a
hug
Jack <mr*********@nospam.jackpot.uk.net> wrote:
Alan J. Flavell wrote:
"This response is primarily intended to allow input for actions to
take place without causing a change to the user agent's active
document view,..."


It's usually best confined to situations where the user will get some
independent confirmation out-of-band that the request has been
successful. Otherwise, they're liable to keep repeating the command
in the belief that nothing has happened yet.
Using it as the response to a conditional request instead of
not-modified seems wrong,


I think so too.


As I read it, the 204 specifically tells the browser not to change the
document view; the 304 says that the document content on the server is
not different from the client's copy.

So supposing the document view is currently http://example.com/foo, and
http://example.com/bar is requested, the two responses would have quite
different results. In the case of a 304, the UA would display the cached
copy of bar, whereas a 204 response should cause it to continue
displaying foo.


That's how I read it too. I don't see any reason to fiddle with the
"no content" response header at all, since the only valid reason for
using it seems to be in response to a form-post, and in that case I
want to give a definite visual indication that something has happened.

What tool will run on a win2000 system that will enable me to view
server responses? They provide a version of telnet but it seems
pretty bare-nekkid and assumes that you're a many-year telnet guru.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #17

P: n/a
..oO(hug)
What tool will run on a win2000 system that will enable me to view
server responses? They provide a version of telnet but it seems
pretty bare-nekkid and assumes that you're a many-year telnet guru.


What about Firefox and the "Live HTTP Headers" extension?

Micha
May 10 '06 #18

P: n/a
On Tue, 9 May 2006, hug wrote:
What tool will run on a win2000 system that will enable me to view
server responses?


Ethereal, as I already said.
http://www.ethereal.com/distribution/win32
May 10 '06 #19

P: n/a
hug wrote:

What tool will run on a win2000 system that will enable me to view
server responses? They provide a version of telnet but it seems
pretty bare-nekkid and assumes that you're a many-year telnet guru.


The Windows version of Telnet is also broken in several regards, and
it's a pain to use it for playing with HTTP.

I wrote a tool in Java for this purpose; it's a web-proxy that logs just
about everything passing under its nose to on-screen windows. it allows
me to trace through multiple redirects, showing me all the inbound and
outbound headers for each request, and it's much easier on my head than
Etherreal. Because it's a proxy, you just create requests using whatever
client you're trying to test. You can't do that with Telnet.

I don't know of anything else, freeware or pay-for, that does the same
job, but I haven't looked for a few years. Unfortunately it's not in
good enough shape to be distributed at the moment, so you may be stuck
with Etherreal. There's almost certinly a Linux tool that does most of
it, but I can't name one.

--
Jack.
May 10 '06 #20

P: n/a
hug
hug <contact_info@sig_line.clickit> wrote:

<snipped>

I have discovered the source of the problem, it's now a fairly simple
matter of fixing it. I want to say "thanks" to everyone who helped or
tried to help.

The problem was the result of what I consider to be a design flaw on
the part of Opera 6.05

Apparently the caching on that version retained only the html source
code, rather than the fully-rendered page, in order to conserve
storage. The file in question was a file "index.shtml" which
contained nothing except an SSI include. The server code was properly
sending the not-modified response header. Opera was rendering the
source code it had in cache. SSI includes are as you no doubt know
specified within an html comment. The result was that when the server
sent a not-modified response, Opera rendered a blank page. I
mistakenly assumed it to be an error on my part.

Or perhaps it is a bug in whatever ancient version of SSI is running
in conjunction with whatever version of apache is running on my shared
server. No way to tell for sure that's worth going after imo. There
may be someone who cares to dig further into the true source of the
problem, or not. The exact symptom if anyone cares to try and
reproduce it is a file whose contents consist of nothing more than a
single SSI include of a PHP file. I'm really not sure who processes
SSI includes and unfortunately neither do I have time to dig since I
can solve the immediate problem and move forward without knowing for
certain.

Perhaps this post will come up when someone else is seeing the effects
of this design flaw, or bug, as the case may be. Thanks again.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #21

P: n/a
VK

hug wrote:
I tried the "no content" header, in -addition- to the usual response
headers, and it made no difference. I will not even bother trying it
-without- the headers that the spec calls for.


I may be deeply wrong but you are doing something really weird with the
poor HTTP :-)

Also you seem to presume that:
1) the proper Last-Modified date for a dynamic data source is an act of
the Lord.
It is not - you have to set it in response yourselve by checking the
bound data source against of the received request.

2) All UA's set If-Modified-Since request header and do care of the
relevant response header.
They don't, at least far of all of them. Mostly on GET request they
expect some content with Last-Modified date set, and they use this date
to keep/update/expire the cached versions of the same page. And this
only if the UA setting "Refresh" or equivalent is not set to "Never".

Overall I would like to see exact request headers you send /to/ the
server and exact response headers you send back /from/ the server
(content is irrelevant).

I'm sniky suspicious that you have a dialog of two deafs :-) The one
(client) is asking "send me this content only if it changed since this
date", the other (server) sends the content and says "here is the
content, it was last changed at this date".

Someone has to ask properly, and the other side actually listen the
request :-)

May 10 '06 #22

P: n/a
hug wrote:
hug <contact_info@sig_line.clickit> wrote:

<snipped>

The problem was the result of what I consider to be a design flaw on
the part of Opera 6.05
Seems highly unlikely, in the light of the remarks that follow:
Apparently the caching on that version retained only the html source
code, rather than the fully-rendered page, in order to conserve
storage. The file in question was a file "index.shtml" which
contained nothing except an SSI include. The server code was
properly sending the not-modified response header. Opera was
rendering the source code it had in cache.
How on earth did Opera (or any other UA) get a hold of that then?
SSI includes are as you no doubt know specified within an html
comment. The result was that when the server sent a not-modified
response, Opera rendered a blank page. I mistakenly assumed it to be
an error on my part.


SSI, as apparently you don't know, are include files that are supposed
to be processed on the server side. Neither Opera nor any other UA is
meant to be dealing with SSI directives. Opera should only ever have
received rendered versions of the page.

So if Apache sent a Not-Modified header, then either it didn't
know it was dealing with SSI (most likely) or it determined that the
rendered HTML really hadn't changed (unlikely). Either way, the UA
should never have seen the SSI source, so it shouldn't have had it cached.

I suspect a misconfigured instance of Apache, or possibly a bad include
directive. But there's nothing here to suggest any kind of defect in Opera.

--
Jack.
May 10 '06 #23

P: n/a
On Tue, 9 May 2006, Jack wrote:
SSI, as apparently you don't know, are include files that are
supposed to be processed on the server side. Neither Opera nor any
other UA is meant to be dealing with SSI directives. Opera should
only ever have received rendered versions of the page.
You took the words right out of my mouth! SCNR.

[...]
But there's nothing here to suggest any kind of defect in Opera.


Not on the basis of what "hug" has described, no. If you care for
a second opinion, I fully agree with your findings.
May 10 '06 #24

P: n/a
hug wrote:
The file in question was a file "index.shtml" which
contained nothing except an SSI include. The server code was properly
sending the not-modified response header. Opera was rendering the
source code it had in cache. SSI includes are as you no doubt know
specified within an html comment. The result was that when the server
sent a not-modified response, Opera rendered a blank page.


SSI includes are not "a HTML comment". They're an SSI statement that
just happens to look like one. 8-)

As far as HTML goes, then the only thing round here that processes HTML
is Opera, and that shouldn't be seeing _anything_ to do with either the
SSI or the "comment" it's represented as. By the time this HTML leaves
your server then the include is aggregated and ironed out flat into
plain old HTML - no SSI and no comment.

If Opera sees the SSI _as_ a comment, then something around the server
is screwing up (it's not processing the SSI, so it truly does become a
"HTML comment").

I'm always suspicious of servers generating "modified" dates for things
that are either dynamic or based on aggregating include files. They've
been known to get it wrong before.

Can you see what's in Opera's cache? Does the "page" have a reasonable
datestamp on it, and does the content look rational? Even if it is a
"comment" that ought to have been processed by SSI, then it should be
viewable as such in the source. That's definitely a server error.

May 10 '06 #25

P: n/a
hug
Michael Fesser <ne*****@gmx.de> wrote:
.oO(hug)
What tool will run on a win2000 system that will enable me to view
server responses? They provide a version of telnet but it seems
pretty bare-nekkid and assumes that you're a many-year telnet guru.


What about Firefox and the "Live HTTP Headers" extension?

Micha


Not familiar with it, is that what you use?

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #26

P: n/a
hug
"VK" <sc**********@yahoo.com> wrote:
I may be deeply wrong but you are doing something really weird with the
poor HTTP :-)


I may be deeply wrong, but it is my perception that you couldn't find
your ass with a flashlight and a stinkmeter.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #27

P: n/a
hug
"Andy Dingley <di*****@codesmiths.com>" <di*****@codesmiths.com>
wrote:
Can you see what's in Opera's cache? Does the "page" have a reasonable
datestamp on it, and does the content look rational? Even if it is a
"comment" that ought to have been processed by SSI, then it should be
viewable as such in the source. That's definitely a server error.


Can't see a thing. View source presents an empty file. The only way
I know this is what's going on is that if I add some text to the
index.shtml the text shows up (but the SSI include remains
unprocessed).

I've been assuming that this old version of Opera was doing some kind
of nekkid get that bypassed SSI. More and more it's sounding like an
SSI bug.

SSI has never impressed me very much. I think that I'll do away with
using it entirely.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #28

P: n/a
On Tue, 9 May 2006, Andy Dingley <di*****@codesmiths.com> wrote:
I'm always suspicious of servers generating "modified" dates for
things that are either dynamic or based on aggregating include
files. They've been known to get it wrong before.


"XBitHack full" does what it says on the tin. If it's what you want,
(in my case it usually is) then use it. If it isn't, then at least
they told you clearly about it, there's no mystery.

There *used* to be a third party module which cooked-up the last
change stamps of all the files involved, and returned the newest one.
But I haven't seen it discussed recently.

[other good advice snipped]
May 10 '06 #29

P: n/a
..oO(hug)
Michael Fesser <ne*****@gmx.de> wrote:
What about Firefox and the "Live HTTP Headers" extension?


Not familiar with it, is that what you use?


Yep, if I want to test my local server:

http://livehttpheaders.mozdev.org/

For testing servers on the WWW I sometimes use this one:

http://web-sniffer.net/

HTH
Micha
May 10 '06 #30

P: n/a
hug
Michael Fesser <ne*****@gmx.de> wrote:
.oO(hug)
Michael Fesser <ne*****@gmx.de> wrote:
What about Firefox and the "Live HTTP Headers" extension?


Not familiar with it, is that what you use?


Yep, if I want to test my local server:

http://livehttpheaders.mozdev.org/

For testing servers on the WWW I sometimes use this one:

http://web-sniffer.net/

HTH
Micha


Thanks Michael.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #31

P: n/a
VK

hug wrote:
I may be deeply wrong, but it is my perception that you couldn't find
your ass with a flashlight and a stinkmeter.


Yes I can: I just need a mirror and a bit of light :-)

But you amuse me a lot - like any people though without any idea of
what are they doing but with a strongest feeling that they do know it
in all details :-) (this is why politicians are often better than any
Saturday Night's show)

At <http://www.nskom.com/external/tmp/http/204.cgi> there is a
primitive script sending either an HTML page or 204 No Content based on
a random generator. The script itself is as primitive as:

#!/usr/bin/perl
$rnd = int(rand(7));
$tmp = gmtime(time);
if ($rnd <= 3) {
print "Content-Type:text/html; charset=ISO-8859-1\n\n";
print "<html><head><title>Demo</title></head>";
print "<body><pre>$tmp</pre></body></html>";
}
else {
print "Status:204 No Content\n\n";
}

Try it on any UA you have available. After that re-read the specs with
a sample in front of your eyes. That helps greatly to actually
understand the words and their real meaning.

Later you can run to buy a flashlight and a stinkmeter for me, or you
can ask to explain the 304 header mechanics and usage (the latter will
save you a trip to the store and overall will be free of charge :-)

May 10 '06 #32

P: n/a
hug wrote:

I've been assuming that this old version of Opera was doing some kind
of nekkid get that bypassed SSI. More and more it's sounding like
an SSI bug.
First it's an Opera bug, then it's a bug in the Apache SSI code. But I'd
say there might be just the slightest possibility that it could be
something you're doing wrong.
SSI has never impressed me very much. I think that I'll do away with
using it entirely.


There is a danger that if you "do away with" every piece of software
that you think has a bug in it, you might not end up with a lot of
software. Most of the time, I find that it's more likely that my fresh
code, barely tested and not yet in production, is more likely to have
bugs in it than a standard Apache module that's in use in hundreds of
thousands of production web-servers.

--
Jack.
May 10 '06 #33

P: n/a
hug
Jack <mr*********@nospam.jackpot.uk.net> wrote:
hug wrote:

I've been assuming that this old version of Opera was doing some kind
of nekkid get that bypassed SSI. More and more it's sounding like
an SSI bug.


First it's an Opera bug, then it's a bug in the Apache SSI code. But I'd
say there might be just the slightest possibility that it could be
something you're doing wrong.


If you reread the original post, you will see where I stated that I
was betting on the problem being in my code.

The root of the problem was/is in my code (since I haven't gotten
around to fixing it yet), when an if-modified-since comes in for a
shtml file that contains SSI includes I'm presenting the wrong reply
header, not-modified; I'll fix that as soon as I can get to it, but at
the moment other things are going on.

What I still do not understand is why, when Opera receives the
not-modified, it renders only the contents of the shtml file without
the SSI include being rendered. That shouldn't happen. It shouldn't
be possible for Opera to get the nekkid shtml file to begin with. I
don't yet know what is going on or why. I'm not done with this issue
yet.
SSI has never impressed me very much. I think that I'll do away with
using it entirely.


There is a danger that if you "do away with" every piece of software
that you think has a bug in it, you might not end up with a lot of
software. Most of the time, I find that it's more likely that my fresh
code, barely tested and not yet in production, is more likely to have
bugs in it than a standard Apache module that's in use in hundreds of
thousands of production web-servers.


The server code that we're talking about already contains include
facilities (tested and in production) that are much more powerful than
SSI (which imo has always been a poster-child for the crippled
software society). SSI just plain doesn't offer much functionality.
Of course no coding is required to use it, so maybe getting a little
for free is not too bad.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #34

P: n/a
hug
"VK" <sc**********@yahoo.com> wrote:

hug wrote:
I may be deeply wrong, but it is my perception that you couldn't find
your ass with a flashlight and a stinkmeter.
Yes I can: I just need a mirror and a bit of light :-)


You have a sense of humor instead of a thin skin, I like that. (It
also bodes well for your continued survival in usenetland. <g>)
But you amuse me a lot - like any people though without any idea of
what are they doing but with a strongest feeling that they do know it
in all details :-) (this is why politicians are often better than any
Saturday Night's show)
I too have a sense of humor, and some actual experience (though not
that much experience with internet client/server, I'm still coming up
to speed).
At <http://www.nskom.com/external/tmp/http/204.cgi> there is a
primitive script sending either an HTML page or 204 No Content based on
a random generator. The script itself is as primitive as:

#!/usr/bin/perl
$rnd = int(rand(7));
$tmp = gmtime(time);
if ($rnd <= 3) {
print "Content-Type:text/html; charset=ISO-8859-1\n\n";
print "<html><head><title>Demo</title></head>";
print "<body><pre>$tmp</pre></body></html>";
}
else {
print "Status:204 No Content\n\n";
}

Try it on any UA you have available. After that re-read the specs with
a sample in front of your eyes. That helps greatly to actually
understand the words and their real meaning.
As far as I can tell, the fact that a 204 response header appears to
work (haven't played with your sample) is coincidence and using it
would be a "hack".
Later you can run to buy a flashlight and a stinkmeter for me,
Sorry, given my budget you'll need to use a mirror instead of the
flashlight and both hands instead of the stinkmeter.
or you
can ask to explain the 304 header mechanics and usage (the latter will
save you a trip to the store and overall will be free of charge :-)


Feel free to explain whatever you choose to explain, I will read your
posts and attempt (though I may very well fail) to be civil.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #35

P: n/a
VK

hug wrote:
As far as I can tell, the fact that a 204 response header appears to
work (haven't played with your sample) is coincidence and using it
would be a "hack".
204 No Content header is an official documented HTTP/1 header, so I'm
not sure how could it be a "hack". Its application domain are the
situations where you want to send a request, but in response you are
interested only if your request processed properly or not (thus you are
not interested in the content unless it contains something new to
show). In this regard 204 (request OK, but no new content) or an error
(request failed) is just fine in many situations.
Feel free to explain whatever you choose to explain, I will read your
posts and attempt (though I may very well fail) to be civil.


Just leave my a** in peace ;-)

Here is another sample to play with:
<http://www.nskom.com/external/tmp/http/cache.cgi>

The script behind is forcely a bit more complicated. A good part of it
is taken by the sub generating proper date in RFC1123 format. A great
mistery to me of all known server-side scripting languages (Perl, PHP,
JSP, ASP etc):- this absolutely necessary format is not available by
default language tools. I don't know either it's a negligeance,
lazyness or a tradition to leave it as a "Hello World!" exercise.
#!/usr/bin/perl

$date = &rfc1123;

if (&newData) {
# EOA (Expired On Arrival):
print "Date: $date\n";
print "Expires: $date\n";
print "Content-Type: text/html; iso-8859-1\n\n";
print '<html><head><title>Demo</title></head>';
print "<body><pre>\n\t$date</pre></body></html>";
}
elsif ( defined($ENV{HTTP_IF_MODIFIED_SINCE}) ){
die;
}
else {
print "Date: $date\n";
print "Expires: $date\n";
print "Status: 204 No Content\n\n";
}
exit(0);

sub newData {
my $rnd = int(rand(7));
return ($rnd < 3) ? 0 : 1;
}

sub rfc1123 {
# RFC850 rev. RFC1123
my @wd = qw(Mon Tue Wed Thu Fri Sat Sun);
my @mo = qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec);
my @t = gmtime(time);;
my($y, $d, $h, $m, $s);

$y = $t[5] + 1900;
$d = ($t[3] < 10) ? '0'.$t[3] : $t[3];
$h = ($t[2] < 10) ? '0'.$t[2] : $t[2];
$m = ($t[1] < 10) ? '0'.$t[1] : $t[1];
$s = ($t[0] < 10) ? '0'.$t[0] : $t[0];

return "$wd[$t[6]], $d $mo[$t[4]] $y $h:$m:$s GMT";
}
Comments:
1) In theory any cached page may be in two states: fresh (not expired
upon headers) and stale (expired upon headers). If you call a page
which is cached but stale, UA supposes to validate this page before
displaying: thus contact the origin server and check if the page was
updated. In this beautiful theory exactly for this situation
(validating stale page) UA /may/ make a conditional GET request with
If-Modified-Since header, and server supposes to answer either with new
page or with 304 Not Modified. That's a beautiful theory of a kind "all
people on the Earth are brothers and sisters". :-)

In case if any UA indeed sends If-Modified-Since, we have "die"
instruction in the script, so you'll see the unfamous 500 Error. Don't
be shy to hit refresh and address bar as long as you want to get this
error.
Note: HTTP_IF_MODIFIED_SINCE is simply Perl's translit of the relevant
HTTP header.

2) Respectively - and the specs are rather clear on it - if you did not
receive a conditional GET request (say with If-Modified-Since header
set), then there is no use to send back 304 Not Modified, because the
recipient is not interested in such answer and it is not instructed to
listen for it.

Briefly and plainly:
- Req: I want to GET this page (without If-Modified-Since)
- Res: This page is Not Modified

is an equivalent of a "dialog" like:

- Req: What are you doing tonight?
- Res: Yes, today is really hot.

3) By refreshing the page several times and trying to navigate back
later, you see right away big differences in caching mrchanics in
different UA's
It is understandable because the caching is "the core and the soul" :-)
of any UA. It defines a great part of usability thus the caching
neuristics is one of the most complicated and often copyrighted part of
the UA's. In this aspect HTTP headers' "baby talk" is only the starting
point from where the relevant engineer teams moved forward.

4) In the script the actual db request is emulated by random generator
in newData sub. On a real run it will be MySGL, PostgreSQL or another
database request. But the nature of the situation doesn't change: the
HTTP mediator (this script) has no means to know if data has changed or
not. Respectively it cannot set any reasonable Last-Modified header.
You (your database driver) has to check the data against the request
and inform the mediator.

5) Overall for dynamic sources simply serve all responses with
cache-preventing headers (kill the Kenny :-). Mostly (but no guarantees
of any kind) UA will re-query for the same page from the server, where
you can take some decisions.

6) An icing on the cake: Opera doesn't check the cache expiration at
all when going back and forwards in the history - it does it only when
you click a link.

7) The huge popularity of IXMLHTTPRequest/XMLHttpRequest (aka AJAX) may
get a bit clearer now.

May 10 '06 #36

P: n/a
..oO(VK)
Here is another sample to play with:
<http://www.nskom.com/external/tmp/http/cache.cgi>

The script behind is forcely a bit more complicated. A good part of it
is taken by the sub generating proper date in RFC1123 format. A great
mistery to me of all known server-side scripting languages (Perl, PHP,
JSP, ASP etc):- this absolutely necessary format is not available by
default language tools. I don't know either it's a negligeance,
lazyness or a tradition to leave it as a "Hello World!" exercise.
<?php print gmdate(DATE_RFC1123)?>

(PHP 5.1)
print "Date: $date\n";
print "Expires: $date\n";
print "Content-Type: text/html; iso-8859-1\n\n";
I also send ETag and Cache-Control headers.
Comments:
1) In theory any cached page may be in two states: fresh (not expired
upon headers) and stale (expired upon headers). If you call a page
which is cached but stale, UA supposes to validate this page before
displaying: thus contact the origin server and check if the page was
updated. In this beautiful theory exactly for this situation
(validating stale page) UA /may/ make a conditional GET request with
If-Modified-Since header, and server supposes to answer either with new
page or with 304 Not Modified. That's a beautiful theory of a kind "all
people on the Earth are brothers and sisters". :-)
It does work this way in my browsers (recent Opera and FF). If necessary
they send a conditional GET with If-Modified-Since and/or If-None-Match
headers.
5) Overall for dynamic sources simply serve all responses with
cache-preventing headers (kill the Kenny :-). Mostly (but no guarantees
of any kind) UA will re-query for the same page from the server, where
you can take some decisions.


I always try to keep my resources cacheable, even if they are generated
dynamically. I use a server-side cache and allow the UAs to consider a
fetched resource as fresh for some time, before they have to revalidate.
This can save a lot of traffic.

Micha
May 10 '06 #37

P: n/a
VK

Michael Fesser wrote:
.oO(VK)
A great
mistery to me of all known server-side scripting languages (Perl, PHP,
JSP, ASP etc):- this absolutely necessary format is not available by
default language tools. I don't know either it's a negligeance,
lazyness or a tradition to leave it as a "Hello World!" exercise.
<?php print gmdate(DATE_RFC1123)?>

(PHP 5.1)


Oh, they finally added it in the core? Took five releases, but better
later than never :-)
AFAIK RFC1123 expects "GMT" identifier, not "UTC"; from the other side
servers should be forgiveful on that.
print "Date: $date\n";
print "Expires: $date\n";
print "Content-Type: text/html; iso-8859-1\n\n";


I also send ETag and Cache-Control headers.


There are a lot of things to send in HTTP. A lot of reasonable useful
things made for a disciplined reasonable world :-) But as the latter
doesn't exists, you cannot tell if it will be actually regarded on the
other end and even if - you cannot tell in what manner will it be
regarded (unless intranet).

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.

At the same time it considers each refresh request of the same page as
new item in the history (if Expires is set properly). At the same time
Firefox sees only one item in the history no matter what headers say.
Go to <http://www.nskom.com/external/tmp/http/cache.cgi>, refresh the
page several times and try Back in both browsers.

That is the major problem with GET on dynamic sources: you can make
only very rough guesses of how the actual refresh will work for the
recipients: it all depends on UA's default caching mechanics and only
just a bit on HTTP headers.

This is why people just jumped on AJAX because it allows to create a
"browser within browser" with platform-independent refresh mechanics
and the needed communication with the server (via setRequestHeader).
There is another price to pay in AJAX though, so it's always a per
solution decision.
Comments:
1) In theory any cached page may be in two states: fresh (not expired
upon headers) and stale (expired upon headers). If you call a page
which is cached but stale, UA supposes to validate this page before
displaying: thus contact the origin server and check if the page was
updated. In this beautiful theory exactly for this situation
(validating stale page) UA /may/ make a conditional GET request with
If-Modified-Since header, and server supposes to answer either with new
page or with 304 Not Modified. That's a beautiful theory of a kind "all
people on the Earth are brothers and sisters". :-)


It does work this way in my browsers (recent Opera and FF). If necessary
they send a conditional GET with If-Modified-Since and/or If-None-Match
headers.


I guess then than "if necessary" doesn't cover the expired Expires
header? I'm testing on Opera 9 Beta. Do you have a public page to look
at?

I always try to keep my resources cacheable, even if they are generated
dynamically. I use a server-side cache and allow the UAs to consider a
fetched resource as fresh for some time, before they have to revalidate.
This can save a lot of traffic.


Are you in intranet?

May 10 '06 #38

P: n/a
hug
Michael Fesser <ne*****@gmx.de> wrote:
.oO(VK)
Here is another sample to play with:
<http://www.nskom.com/external/tmp/http/cache.cgi>

The script behind is forcely a bit more complicated. A good part of it
is taken by the sub generating proper date in RFC1123 format. A great
mistery to me of all known server-side scripting languages (Perl, PHP,
JSP, ASP etc):- this absolutely necessary format is not available by
default language tools. I don't know either it's a negligeance,
lazyness or a tradition to leave it as a "Hello World!" exercise.


<?php print gmdate(DATE_RFC1123)?>

(PHP 5.1)
print "Date: $date\n";
print "Expires: $date\n";
print "Content-Type: text/html; iso-8859-1\n\n";


I also send ETag and Cache-Control headers.
Comments:
1) In theory any cached page may be in two states: fresh (not expired
upon headers) and stale (expired upon headers). If you call a page
which is cached but stale, UA supposes to validate this page before
displaying: thus contact the origin server and check if the page was
updated. In this beautiful theory exactly for this situation
(validating stale page) UA /may/ make a conditional GET request with
If-Modified-Since header, and server supposes to answer either with new
page or with 304 Not Modified. That's a beautiful theory of a kind "all
people on the Earth are brothers and sisters". :-)


It does work this way in my browsers (recent Opera and FF). If necessary
they send a conditional GET with If-Modified-Since and/or If-None-Match
headers.


The old Opera 6.05 that I'm using seems to send 3 types of GET
request. If it's a new page, there's nothing special in the headers.
If it's a link that's been clicked before, Opera sends
if-modified-since and deals correctly with the response (nevermind the
case of a file containing only one SSI include). If it's a "refresh"
what Opera sends is a GET request with a "Cache-control: none" header.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #39

P: n/a

hug wrote:
The server code that we're talking about already contains include
facilities (tested and in production) that are much more powerful than
SSI


Oh, right ! It's _your_ code on the server. Not only that, but it's
better than everyone else's code.
That's where your bug is then.

And what's this rubbish about Opera doing a "naked get" ? Don't blame
other teams for your bugs.

May 10 '06 #40

P: n/a
hug
"VK" <sc**********@yahoo.com> wrote:

hug wrote:
As far as I can tell, the fact that a 204 response header appears to
work (haven't played with your sample) is coincidence and using it
would be a "hack".


204 No Content header is an official documented HTTP/1 header, so I'm
not sure how could it be a "hack". Its application domain are the
situations where you want to send a request, but in response you are
interested only if your request processed properly or not (thus you are
not interested in the content unless it contains something new to
show). In this regard 204 (request OK, but no new content) or an error
(request failed) is just fine in many situations.
Feel free to explain whatever you choose to explain, I will read your
posts and attempt (though I may very well fail) to be civil.


Just leave my a** in peace ;-)

Here is another sample to play with:
<http://www.nskom.com/external/tmp/http/cache.cgi>

The script behind is forcely a bit more complicated. A good part of it
is taken by the sub generating proper date in RFC1123 format. A great
mistery to me of all known server-side scripting languages (Perl, PHP,
JSP, ASP etc):- this absolutely necessary format is not available by
default language tools. I don't know either it's a negligeance,
lazyness or a tradition to leave it as a "Hello World!" exercise.
#!/usr/bin/perl

$date = &rfc1123;

if (&newData) {
# EOA (Expired On Arrival):
print "Date: $date\n";
print "Expires: $date\n";
print "Content-Type: text/html; iso-8859-1\n\n";
print '<html><head><title>Demo</title></head>';
print "<body><pre>\n\t$date</pre></body></html>";
}
elsif ( defined($ENV{HTTP_IF_MODIFIED_SINCE}) ){
die;
}
else {
print "Date: $date\n";
print "Expires: $date\n";
print "Status: 204 No Content\n\n";
}
exit(0);

sub newData {
my $rnd = int(rand(7));
return ($rnd < 3) ? 0 : 1;
}

sub rfc1123 {
# RFC850 rev. RFC1123
my @wd = qw(Mon Tue Wed Thu Fri Sat Sun);
my @mo = qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec);
my @t = gmtime(time);;
my($y, $d, $h, $m, $s);

$y = $t[5] + 1900;
$d = ($t[3] < 10) ? '0'.$t[3] : $t[3];
$h = ($t[2] < 10) ? '0'.$t[2] : $t[2];
$m = ($t[1] < 10) ? '0'.$t[1] : $t[1];
$s = ($t[0] < 10) ? '0'.$t[0] : $t[0];

return "$wd[$t[6]], $d $mo[$t[4]] $y $h:$m:$s GMT";
}
Comments:
1) In theory any cached page may be in two states: fresh (not expired
upon headers) and stale (expired upon headers). If you call a page
which is cached but stale, UA supposes to validate this page before
displaying: thus contact the origin server and check if the page was
updated. In this beautiful theory exactly for this situation
(validating stale page) UA /may/ make a conditional GET request with
If-Modified-Since header, and server supposes to answer either with new
page or with 304 Not Modified. That's a beautiful theory of a kind "all
people on the Earth are brothers and sisters". :-)

In case if any UA indeed sends If-Modified-Since, we have "die"
instruction in the script, so you'll see the unfamous 500 Error. Don't
be shy to hit refresh and address bar as long as you want to get this
error.
Note: HTTP_IF_MODIFIED_SINCE is simply Perl's translit of the relevant
HTTP header.

2) Respectively - and the specs are rather clear on it - if you did not
receive a conditional GET request (say with If-Modified-Since header
set), then there is no use to send back 304 Not Modified, because the
recipient is not interested in such answer and it is not instructed to
listen for it.

Briefly and plainly:
- Req: I want to GET this page (without If-Modified-Since)
- Res: This page is Not Modified

is an equivalent of a "dialog" like:

- Req: What are you doing tonight?
- Res: Yes, today is really hot.

3) By refreshing the page several times and trying to navigate back
later, you see right away big differences in caching mrchanics in
different UA's
It is understandable because the caching is "the core and the soul" :-)
of any UA. It defines a great part of usability thus the caching
neuristics is one of the most complicated and often copyrighted part of
the UA's. In this aspect HTTP headers' "baby talk" is only the starting
point from where the relevant engineer teams moved forward.

4) In the script the actual db request is emulated by random generator
in newData sub. On a real run it will be MySGL, PostgreSQL or another
database request. But the nature of the situation doesn't change: the
HTTP mediator (this script) has no means to know if data has changed or
not. Respectively it cannot set any reasonable Last-Modified header.
You (your database driver) has to check the data against the request
and inform the mediator.

5) Overall for dynamic sources simply serve all responses with
cache-preventing headers (kill the Kenny :-). Mostly (but no guarantees
of any kind) UA will re-query for the same page from the server, where
you can take some decisions.

6) An icing on the cake: Opera doesn't check the cache expiration at
all when going back and forwards in the history - it does it only when
you click a link.

7) The huge popularity of IXMLHTTPRequest/XMLHttpRequest (aka AJAX) may
get a bit clearer now.


Thanks for typing all that stuff in. I didn't see any new/relevant
information, but thanks anyway.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #41

P: n/a
..oO(VK)
Michael Fesser wrote:

<?php print gmdate(DATE_RFC1123)?>

(PHP 5.1)
Oh, they finally added it in the core? Took five releases, but better
later than never :-)
AFAIK RFC1123 expects "GMT" identifier, not "UTC"; from the other side
servers should be forgiveful on that.


When called with gmdate() it returns a "GMT" on my system.
It does work this way in my browsers (recent Opera and FF). If necessary
they send a conditional GET with If-Modified-Since and/or If-None-Match
headers.


I guess then than "if necessary" doesn't cover the expired Expires
header?


Hmm, actually I'm not sending an Expires header yet. Currently it's just
a max-age value in the Cache-Control header.
I'm testing on Opera 9 Beta.
Me too.
Do you have a public page to look
at?


Since I'm still working on that cache thing, I don't have it enabled by
default on "live" sites. But for testing you can have a look at this:

http://ra-pauli.allpakallpa.com/

(work in progress)
I always try to keep my resources cacheable, even if they are generated
dynamically. I use a server-side cache and allow the UAs to consider a
fetched resource as fresh for some time, before they have to revalidate.
This can save a lot of traffic.


Are you in intranet?


Nope.

Micha
May 10 '06 #42

P: n/a
hug
"Andy Dingley <di*****@codesmiths.com>" <di*****@codesmiths.com>
wrote:

hug wrote:
The server code that we're talking about already contains include
facilities (tested and in production) that are much more powerful than
SSI
Oh, right ! It's _your_ code on the server. Not only that, but it's
better than everyone else's code.
That's where your bug is then.


Andy, are you trying to start a war, or just feeling pissy this
morning?
And what's this rubbish about Opera doing a "naked get" ? Don't blame
other teams for your bugs.


Please feel free to explain why Opera 6.05 when presented with a
not-modified response to an if-modified-since request renders a blank
page for a shtml file that includes only a single SSI include.

I'm wondering what server configuration problems might cause this
bizarre happening. I haven't reached any definite conclusions except
that what I am seeing on the Opera screen is not what I expect to see.

Knowing more about what's going on it's an easy fix, but instead of
just fixing it away I'd like to understand why it's happening.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #43

P: n/a
hug wrote:
Andy, are you trying to start a war, or just feeling pissy this
morning?
I'm just sick of seeing people blaming anything and everything in sight
for problems when the only thing that's new and untested out there is
their own code. If it's not people "bug finding in the W3C validator"
it's others re-interpreting the specs to suit their own
wish-fulfillment.
And what's this rubbish about Opera doing a "naked get" ? Don't blame
other teams for your bugs.

Please feel free to explain why


Why should I ? We've not even got a URL to look at.

It's not exactly hard to diagnose this problem, yet you haven't managed
to do that much without inventing entirely specious explanations (the
"naked GET") of why it has to be anyone else's fault but your own code.

Stick some markers in the code outside the SSI "comment", and see if
Opera downloads them. Watch the network traffic and see what's sent
where. These are basic diagnostic techniques, yet you haven't even
tried them.

Possibly Opera has a bug. Possibly it gets the not-modified response
and treats it as a 200 with an empty page body. But it's easy to
_prove_ that's what Opera is doing and you haven't done that, you've
built castles in the air instead. Then several posts later we find out
that the SSI processor wasn't Apache or (Bob forbid) even IIS, but it's
some of your own-rolled code. That puts a whole new light on the
problem (and means we've all been chasing red herrings).

Nothing personal, but compared to Apache or Opera then your code sucks
(and so does mine). We just haven't run several kilogeeks of beta
testers over it in the way that they have. If _anything_ is likely to
be broken, it's the new stuff and that means your stuff.

Now I've got my own bugs to worry about. Mine, my fault, my mess to
clear up. I'm not blaming Python or SVN for them, they're all my own
work.

May 10 '06 #44

P: n/a
On Wed, 10 May 2006, hug wrote:
Please feel free to explain why Opera 6.05 when presented with a
not-modified response to an if-modified-since request renders a
blank page for a shtml file that includes only a single SSI include.
As you've already been told before, "SSI includes" have no business
being presented to a browser. They're meant to be resolved *by the
server*, before being served-out.

In the event that they do unintentionally leak out, as seems to have
happened here, they take the form of an HTML comment, so the browser
is behaving correctly by displaying a "blank" page.
I'm wondering what server configuration problems might cause this
bizarre happening.
So are we. You see, it *is* a server-side problem.
I haven't reached any definite conclusions except
that what I am seeing on the Opera screen is not what I expect to see.
No - you've already been told that what your server is serving out is
not what it's supposed to. What you're seeing on the browser is just
a later consequence of that.

I've always found that the key to problem solving is to break the
problem into manageable component parts, and understand each
separately, before building them into a whole. As far as we've heard
the story so far, you still seem to have some quivering heap of code,
that you don't entirely understand yourself, let alone being able to
explain it to us (I mean, this group).
Knowing more about what's going on it's an easy fix, but instead of
just fixing it away I'd like to understand why it's happening.


I can understand Andy getting impatient. Had you met this yet?
He made one, just in case:
http://www.codesmiths.com/shed/things/clueiron/

May 10 '06 #45

P: n/a
hug
"Andy Dingley <di*****@codesmiths.com>" <di*****@codesmiths.com>
wrote:
hug wrote:
Andy, are you trying to start a war, or just feeling pissy this
morning?
I'm just sick of seeing people blaming anything and everything in sight
for problems when the only thing that's new and untested out there is
their own code. If it's not people "bug finding in the W3C validator"
it's others re-interpreting the specs to suit their own
wish-fulfillment.


Yeah, I can understand being sick of that, it ain't my problem.
>And what's this rubbish about Opera doing a "naked get" ? Don't blame
>other teams for your bugs.

Please feel free to explain why


Why should I ? We've not even got a URL to look at.

It's not exactly hard to diagnose this problem, yet you haven't managed
to do that much without inventing entirely specious explanations (the
"naked GET") of why it has to be anyone else's fault but your own code.

Stick some markers in the code outside the SSI "comment", and see if
Opera downloads them. Watch the network traffic and see what's sent
where. These are basic diagnostic techniques, yet you haven't even
tried them.


Bullshit, you know dick-all about what I've tried and what I haven't
tried.
Possibly Opera has a bug. Possibly it gets the not-modified response
and treats it as a 200 with an empty page body. But it's easy to
_prove_ that's what Opera is doing and you haven't done that, you've
built castles in the air instead.
I do believe that I posted that I had put text before and after the
SSI include and the text showed up but the included text did not. If
I didn't, you're a fuckwit anyway for ASSSUMING things about what I
have not done.
Then several posts later we find out
that the SSI processor wasn't Apache or (Bob forbid) even IIS, but it's
some of your own-rolled code. That puts a whole new light on the
problem (and means we've all been chasing red herrings).

Nothing personal, but compared to Apache or Opera then your code sucks
(and so does mine). We just haven't run several kilogeeks of beta
testers over it in the way that they have. If _anything_ is likely to
be broken, it's the new stuff and that means your stuff.
Nothing personal, but you don't know shit about my code one way or the
other.
Now I've got my own bugs to worry about. Mine, my fault, my mess to
clear up. I'm not blaming Python or SVN for them, they're all my own
work.


So STUF and go do your own work, asswipe.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #46

P: n/a
hug
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> wrote:
On Wed, 10 May 2006, hug wrote:
Please feel free to explain why Opera 6.05 when presented with a
not-modified response to an if-modified-since request renders a
blank page for a shtml file that includes only a single SSI include.
As you've already been told before, "SSI includes" have no business
being presented to a browser. They're meant to be resolved *by the
server*, before being served-out.


Yeah, I understand that.
In the event that they do unintentionally leak out, as seems to have
happened here, they take the form of an HTML comment, so the browser
is behaving correctly by displaying a "blank" page.
Interesting that the browser displays any text inserted before/after
the SSI include but not the included text.
I'm wondering what server configuration problems might cause this
bizarre happening.


So are we. You see, it *is* a server-side problem.


It probably is, but I'm not ready to jump to that conclusion even
though it makes sense.
I haven't reached any definite conclusions except
that what I am seeing on the Opera screen is not what I expect to see.


No - you've already been told that what your server is serving out is
not what it's supposed to. What you're seeing on the browser is just
a later consequence of that.


I appreciate what I've been told but I tend to validate things before
going off half-cocked. On the server side there are lots of
components that have a hand in the totality of things. There's my
code (most suspect), there's SSI (hey, I didn't set up its config so
there could be anything involved there that I don't know about), then
there's the browser which has been very trustworthy for a long time
but is now giving the appearance of doing something unusual.
I've always found that the key to problem solving is to break the
problem into manageable component parts, and understand each
separately, before building them into a whole.
That's one part of it for sure. Another part is being rigorous about
what you've validated and what you assume.
As far as we've heard
the story so far, you still seem to have some quivering heap of code,
that you don't entirely understand yourself, let alone being able to
explain it to us (I mean, this group).


You got that one way wrong, except the part about explaining it.
Knowing more about what's going on it's an easy fix, but instead of
just fixing it away I'd like to understand why it's happening.


I can understand Andy getting impatient. Had you met this yet?
He made one, just in case:
http://www.codesmiths.com/shed/things/clueiron/


How cute. Andy is sick of the clueless. I can understand that.

You know what I'm sick of? I'm sick to death of pimple-faced kids who
have been in the business for 5 or maybe 10 years, riding high on
their own egos after writing a couple decent programs, ASSUMING
everybody on the planet except them and their cliquies to be idiots.
It just ain't that way. You ask a question in a nosegrope and most
responders ASSUME you to be a total idiot, expect you to give over
your life to their control so THEY can solve your problem because THEY
KNOW. If I'd posted everything I've tried in order to isolate what is
going on no doubt someone would be pissing and moaning about bandwidth
wastage.

Everybody is not a moron, some people just lack a few pieces of
information -- that's DATA, not understanding.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #47

P: n/a
hug wrote:

Andy, are you trying to start a war, or just feeling pissy this
morning?
Andy said what I said - he just said it differently. If it's custom code
against shipped production code, the bug's in the custom code.
And what's this rubbish about Opera doing a "naked get" ? Don't
blame other teams for your bugs.
Please feel free to explain why Opera 6.05 when presented with a
not-modified response to an if-modified-since request renders a blank
page for a shtml file that includes only a single SSI include.


Because the page hasn't been modified.
I'm wondering what server configuration problems might cause this
bizarre happening.
You don't have SSI working.
I haven't reached any definite conclusions except that what I am
seeing on the Opera screen is not what I expect to see.
That's not Opera's fault, judging by your earlier remarks. Opera *still*
has the SSI source cached; and your Apache server is *still* serving raw
SSI to it. Fix the server, clear out the Opera cache, and restart your
testing cycle.
Knowing more about what's going on it's an easy fix, but instead of
just fixing it away I'd like to understand why it's happening.


Fixing it without knowing what's wrong may turn out to be a
time-consuming exercise.

Apache's SSI module has to be both installed and switched on before it
will do its thing with SSI directives. Read the Apache documentation,
and then direct any Apache questions you have to an appropriate
newsgroup. If you don't control the Apache server, then have a word with
the dude who does.

--
Jack.

May 10 '06 #48

P: n/a
hug wrote:
"Alan J. Flavell" <fl*****@physics.gla.ac.uk> wrote:

In the event that they do unintentionally leak out, as seems to
have happened here, they take the form of an HTML comment, so the
browser is behaving correctly by displaying a "blank" page.
Interesting that the browser displays any text inserted before/after
the SSI include but not the included text.


OK, that's a novel meaning for 'blank'.
I'm wondering what server configuration problems might cause this
bizarre happening. So are we. You see, it *is* a server-side problem.


It probably is, but I'm not ready to jump to that conclusion even
though it makes sense.


Good - that's a step forward.

Now: if you have SSI directives in the page on the server; and if those
directives are being delivered, *raw*, to your browser, then it follows
that they are not being expanded by the server. There's possibly some
confusion about the nature of that server - perhaps it's Apache with
mod-ssi, or perhaps it's custom code. It's not a foregone conclusion
that the server is even capable of expanding SSI directives. But if the
server is supposed to be SSI-enabled, then (judging from what you've
said) it seems not to be doing that.

We're about 20 hours down the road now, and you don't seem to have even
got around to clearing out Opera's cache yet. You need to do some tests
- batting posts back and forward on Usenet isn't going to get you much
further (unless you post some code, and a rather more detailed
description of your server setup).
You know what I'm sick of? I'm sick to death of pimple-faced kids
who have been in the business for 5 or maybe 10 years, riding high on
their own egos after writing a couple decent programs, ASSUMING
everybody on the planet except them and their cliquies to be idiots.
If that's what you don't like, then you must find Usenet quite an
annoying place.
It just ain't that way. You ask a question in a nosegrope and most
responders ASSUME you to be a total idiot, expect you to give over
your life to their control so THEY can solve your problem because
THEY KNOW. If I'd posted everything I've tried in order to isolate
what is going on no doubt someone would be pissing and moaning about
bandwidth wastage.
So you have a choice - post too litle, in which case someone might
whinge, and responders are guaranteed to be guessing; or post too much,
in which case someone might whinge.

What you've told us so far says to me that your server won't do SSI; and
you're saying that you don't control that server. It could be that your
plan to give up on SSI might be a good one - but not because there's
anything wrong with SSI as such, which was your second diagnosis (after
bugs in Opera).
Everybody is not a moron, some people just lack a few pieces of
information -- that's DATA, not understanding.


Most people don't have either the temperament or the intellectual rigour
for diagnosing problems in complex systems. That doesn't make them
morons; people like that sometimes make excellent salesmen, or Prime
Ministers.

--
Jack.
May 10 '06 #49

P: n/a
hug
Jack <mr*********@nospam.jackpot.uk.net> wrote:
And what's this rubbish about Opera doing a "naked get" ? Don't
blame other teams for your bugs.
Please feel free to explain why Opera 6.05 when presented with a
not-modified response to an if-modified-since request renders a blank
page for a shtml file that includes only a single SSI include.


Because the page hasn't been modified.


The page as cached from when it was last displayed should be shown.
I'm wondering what server configuration problems might cause this
bizarre happening.


You don't have SSI working.


Could be a configuration problem, yes; but SSI has been including
files on this server for over 3 years and I haven't touched anything
SSI-related lately.
I haven't reached any definite conclusions except that what I am
seeing on the Opera screen is not what I expect to see.


That's not Opera's fault, judging by your earlier remarks. Opera *still*
has the SSI source cached; and your Apache server is *still* serving raw
SSI to it. Fix the server, clear out the Opera cache, and restart your
testing cycle.


So SSI is going to include text for one GET and not for another,
within seconds? Kind of hard to believe.
Knowing more about what's going on it's an easy fix, but instead of
just fixing it away I'd like to understand why it's happening.


Fixing it without knowing what's wrong may turn out to be a
time-consuming exercise.


That's why I avoid that approach.
Apache's SSI module has to be both installed and switched on before it
will do its thing with SSI directives. Read the Apache documentation,
and then direct any Apache questions you have to an appropriate
newsgroup. If you don't control the Apache server, then have a word with
the dude who does.


SSI includes are generallly working fine.

--
http://www.ren-prod-inc.com/hug_soft...action=contact
May 10 '06 #50

102 Replies

This discussion thread is closed

Replies have been disabled for this discussion.