> Hiro Dudani wrote:
> >
> > But unfortunately, it seems another -at least for me much worse- bug has
> > crept in. The symptom I first noticed were frequent "Document contains no
> > data"-popups in Netscape and lots of "broken picture" images. I played
> > around with the options in wwwoffle.conf [1], but to no avail. I finally
> > found what I believe to be the problem when I tried talking to the proxy
> > with Telnet while it was online:
...
> > Now, I don't claim to know a lot about http, but I don't think that a 304
> > should be a valid reply to a request without an "If-modified-since" header,
> > or is it?
> Andrew M. Bishop wrote:
> >
> > You are correct, it is only valid when there is a header like
> > If-Modified-Since or If-None-Match.
...
> > I don't see any way that the reply that you get can be generated by
> > WWWOFFLE for the input that you give. I have tried it on some example
> > pages and I don't see the problem.
> Hiro Dudani wrote:
> >
> > As I already told you off-list, I found out that it is the one in line
> > 1729 of wwwoffles.c that is giving me these problems.
"Paul A. Rombouts" <[EMAIL PROTECTED]> writes:
> I've been experiencing the problem with the many "broken picture" images myself
> and it caused me to revert back to version 2.6d and wait until a fix appeared.
This problem did not exist in the previous versions of WWWOFFLE for a
very simple reason. Previously if there was a conditional request
from the browser then WWWOFFLE would always reply with the entire page
rather than the message that it had not changed. Sending back the
"304" status will optimise the transfer of data between the browser
and WWWOFFLE.
> But you and Andrew gave such tantalizing clues to the cause of the problem that
> I had a look at the code to see if I could fix it myself.
>
> I think I now understand what causes the problem.
> As Andrew said, in wwwoffles.c there are two places where the 304 status code
> can be generated for a reply. These should only be executed if there was an
> If-Modified-Since or If-None-Match header line in the request.
> The fact whether there was such a header line contained in request_head is
> stored in the boolean variables conditional_request_ims and
> conditional_request_inm. However, there are two separate places where these
> variables are assigned values. And between these assignments a function
> RequireChanges can be called with request_head as an argument.
> Unfortunately RequireChanges has the side effect that it can add "If-None-Match"
> and "If-Modified-Since" header lines!
> So after the second assignment to conditional_request_ims and
> conditional_request_inm these variables don't necessarily reflect the fact
> whether the header lines in question where present in the original request made
> by the browser.
> The trouble spot at line 1727 is located after the second assignment.
>
> I attached a patch file to this message which, I hope, fixes the problem.
> The patch seems to work for me.
The patch as supplied should work, but I will make a slightly
different change for the next version. Since the updated
conditional_request_* variables are only used for log file messages I
have moved the lines which update them to just before they are needed.
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.7/user.html
