Proxy problems with Apache 1.3.26 - broken images
Greg Larkin
I came across the message below and it describes my problem exactly.
I have been having all kinds of problems with Apache's mod_proxy now
that I have upgraded from 1.3.6 to 1.3.26. Several of the sites that
I visit load fine once but if I reload them, many of the graphics come
up as broken links. If I turn off the proxy setting in IE, everything
is fine.
It looks like this bug has been around for a little while - does
anyone have any idea how to fix it? I have been playing around with
cache control headers on the web si
5b4
te that I administer, but that hasn't worked yet.
Thanks,
Greg Larkin
[[[original message included here for reference....
From: Goran UnreaL Krajnovic (unr...@fly.srk.fer.hr)
Subject: mod_proxy problems with 1.3.24 for reverse proxying?
Newsgroups: comp.infosystems.www.servers.unix
View this article only
Date: 2002-03-31 13:20:12 PST
Are there any noticed mod_proxy problems with apache 1.3.24? I'm
experimenting with a simple reverse proxy setup (apache as a front-end
web
server for another machine) and I seem to either be missing something
or
having odd problems. The configuration of apache is rather
straightforward
(all of this is inside a VirtualHost directive):
ProxyPass / http://target.site/
ProxyPassReverse / http://target.site/
CacheRoot /usr/local/apache/htdocs/cache/site.name
CacheSize 2048
My symptoms are a bit odd. One the first access to the front server,
proxying and caching seem to work - the (dynamically generated) page
loads
and the cache root is populated with static data - gif images, etc.
However, on subsequent requests to the page, the page still loads but
all
the images stop loading and display the 'broken image' icon.
And indeed, when trying to get the image manually from the proxy, I
get
this:
% telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
GET /images/bijela.gif HTTP/1.1
Host: front.end.se
b68
rver
HTTP/1.1 200 OK
Date: Sun, 31 Mar 2002 21:09:17 GMT
Server: Microsoft-IIS/5.0
Accept-Ranges: bytes
Age: 59
Content-Length: 0
Content-Type: image/gif
ETag: "02ce18baabf1:834"
Last-Modified: Wed, 19 Apr 2000 14:24:56 GMT
X-Cache: HIT from front.end.server
Notice the 'content-length: 0' - I don't get any data back. However,
apache's error log says this:
[Sun Mar 31 23:09:29 2002] [debug] proxy_cache.c(1026): Request for
http://target.site/images/bijela.gif, pragma_req=(null), ims=0
[Sun Mar 31 23:09:29 2002] [debug] proxy_cache.c(1211): Unexpired data
available
[Sun Mar 31 23:09:29 2002] [debug] proxy_cache.c(873): Local copy
modified,
send it
According to the log, mod_proxy claims to have sent the file from
cache to
the client.
And access_log says:
127.0.0.1 - - [31/Mar/2002:23:09:29 +0200] "GET /images/bijela.gif
HTTP/1.1"
200 0 "-" "-"
Which is not status 304, but status 200, but zero bytes sent.
Am I missing something terribly obvious in my configuration? I've
tried
using two different servers as targets for the reverse proxy, so I
assume
it's not some rare and incompatible configuration setting on the
back-end,
and I've tried accessing the proxy using different clients (in hope of
them
using different request headers) but no luck. Also it makes no
difference
whether I request the gif with HTTP/1.0 or HTTP/1.1.
Any help would be appreciated.
--
UnreaL.
[ Standard disclaimers apply. Personal opinions only. May explode in
fire. ]
]]]
Roland Verlander
news:28914a7e.02092...@posting.google.com...
that file from 1.3.6 to 1.3.26) then rebuild apache
Villy Kruse
Greg Larkin <gla...@entropy.com> wrote:
>
>HTTP/1.1 200 OK
>Date: Sun, 31 Mar 2002 21:09:17 GMT
>Server: Microsoft-IIS/5.0
>Accept-Ranges: bytes
>Age: 59
>Content-Length: 0
>Content-Type: image/gif
>ETag: "02ce18baabf1:834"
>Last-Modified: Wed, 19 Apr 2000 14:24:56 GMT
>X-Cache: HIT from front.end.server
>
>Notice the 'content-length: 0' - I don't get any data back. However,
>apache's error log says this:
>
I've patched apache 1.3.26 to compensate for that.
Someone posted a bug report on the apache bug reporting system
sometime this spring, and a few mailing list message has also
occurred on this subject. The conclusion was that Microsoft IIS/5
has a bug causing it to include Content-Length: 0 in a 304 responce,
and Apache will then fix the content lenght in the cached file
and return a zero length data to the browser as it is supposed to
according to the RFC standards.
The 304 responce is the responce from the IIS server itself to the
proxy server when the proxy server includes an If-Modified-Since:
(imf) header in the request to the server. The proxy server does
that when if finds the page already in cache but it has expired.
The Web server is then consulted to check if the cached data is still
valid, and the 304 responce says that the cache is still valid.
The "Age: 59" tells the proxy server that the page will expire
after 59 seconds.
The squid proxy server seems already to handle this situation, that is,
ignoring Content-Length: headers in 304 responces.
Villy
Colin Warner
>On 23 Sep 2002 20:42:06 -0700,
> Greg Larkin <gla...@entropy.com> wrote:
>
>
>>
>>HTTP/1.1 200 OK
>>Date: Sun, 31 Mar 2002 21:09:17 GMT
>>Server: Microsoft-IIS/5.0
>>Accept-Ranges: bytes
>>Age: 59
>>Content-Length: 0
>>Content-Type: image/gif
>>ETag: "02ce18baabf1:834"
>>Last-Modified: Wed, 19 Apr 2000 14:24:56 GMT
>>X-Cache: HIT from front.end.server
>>
>>Notice the 'content-length: 0' - I don't get any data back. However,
>>apache's error log says this:
>I've patched apache 1.3.26 to compensate for that.
Hi Villy, how have you patched 1.3.26, so as not to lose any
functionality please???
Also, do you know if the problem is there is 1.3.24, I wasn't aware of
it in 1.3.6 - maybe all this mean that Apache now works to RFC's and
perhaps once didn't???
>
>Someone posted a bug report on the apache bug reporting system
>sometime this spring, and a few mailing list message has also
>occurred on this subject. The conclusion was that Microsoft IIS/5
>has a bug causing it to include Content-Length: 0 in a 304 responce,
I've done some packet captures with this and IIS 4.0 indicates zero
bytes alright, but this is not a problem if you're using MS Proxy. We
are using MS Proxy, (not a problem) but also wish to use Apache
(problem!!!!) When using MS Proxy the file still gets served up back
to the client PC, it appears to ignore the zero bytes?????
Many Thanks..
Colin Warner Colin@talkback**.worldonline.co.uk
Please remove the "**" from the mail address in reply, or it won't
work
Villy Kruse
Colin Warner <Colin@talkback**.worldonline.co.uk> wrote:
>
>Hi Villy, how have you patched 1.3.26, so as not to lose any
>functionality please???
Inlcuded patch at end of this posting. The only thing the patch does
is to ignore the Content-Length on received 304 messages.
>
>Also, do you know if the problem is there is 1.3.24, I wasn't aware of
>it in 1.3.6 - maybe all this mean that Apache now works to RFC's and
>perhaps once didn't???
>
The problem has been there for quite a few releases, at least back
to 1.3.13. Between v13 and v26 there has been quite a few HTTP/1.1
features included in the caching logic, including aging.
Villy
--- src/modules/proxy/proxy_cache.c.OLD Thu Jul 18 10:27:13 2002
+++ src/modules/proxy/proxy_cache.c Thu Jul 18 12:01:18 2002
@@ -1554,6 +1554,19 @@
/* if response from server 304 not modified */
if (r->status == HTTP_NOT_MODIFIED) {
+ if ((clen = ap_table_get(resp_hdrs, "Content-Length")) != NULL) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_NOERRNO, r->server,
+ "proxy: Ignoring Content-Length: %s"
+ "in HTTP 304 responce "
+ "returned by buggy server %s (%s)",
+ clen, r->uri, r->method);
+ ap_table_unset(resp_hdrs, "Content-Length");
+ if ((clen = ap_table_get(c->hdrs, "Content-Length")) != NULL) {
+ c->len = atoi(clen);
+ ap_proxy_sec2hex(c->len, buff + 17 * (6));
+ buff[17 * (7) - 1] = '\n';
+ buff[17 * (7)] = '\0';
+ }
+ }
+
/* Have the headers changed?
*
* if not - we fulfil the request and return now.
Colin Warner
>On Wed, 25 Sep 2002 21:52:41 +0100,
> Colin Warner <Colin@talkback**.worldonline.co.uk> wrote:
>>
>>Hi Villy, how have you patched 1.3.26, so as not to lose any
>>functionality please???
>
>Inlcuded patch at end of this posting. The only thing the patch does
>is to ignore the Content-Length on received 304 messages.
Hey and it having just been re-compiled, it works just great - Many
Thanks...
>>
>>Also, do you know if the problem is there is 1.3.24, I wasn't aware of
>>it in 1.3.6 - maybe all this mean that Apache now works to RFC's and
>>perhaps once didn't???
>>
>
>The problem has been there for quite a few releases, at least back
>to 1.3.13. Between v13 and v26 there has been quite a few HTTP/1.1
>features included in the caching logic, including aging.
Villy, cheers for your help..
ciao..
Colin..
Co...@talkback.worldonline.co.uk
Villy Kruse
Colin Warner <Co...@talkback.worldonline.co.uk> wrote:
>>The problem has been there for quite a few releases, at least back
>>to 1.3.13. Between v13 and v26 there has been quite a few HTTP/1.1
>>features included in the caching logic, including aging.
>
>Villy, cheers for your help..
>
Then I'll leave it to you to issue a bug report to apache and Microsoft.
Villy
Colin Warner
It seems Apache have solved the problem in their latest release
1.3.27, so they must have been aware of the problem - I thought I'd
read of it being notified to them already on a noticeboard or
something...
Villy Kruse
Colin Warner <Colin@talkback**.worldonline.co.uk> wrote:
>v...@pharmnl.ohout.pharmapartners.nl (Villy Kruse) wrote:
>
>>On Tue, 01 Oct 2002 20:28:13 +0100,
>> Colin Warner <Co...@talkback.worldonline.co.uk> wrote:
>
>>>>The problem has been there for quite a few releases, at least back
>>>>to 1.3.13. Between v13 and v26 there has been quite a few HTTP/1.1
>>>>features included in the caching logic, including aging.
>>>
>>>Villy, cheers for your help..
>>
>>Then I'll leave it to you to issue a bug report to apache and Microsoft.
>
>It seems Apache have solved the problem in their latest release
>1.3.27, so they must have been aware of the problem - I thought I'd
>read of it being notified to them already on a noticeboard or
>something...
>
See bugzille bug number 7847 on the apache web site. Also the mailing
list apache-httpd-dev aound 6 May 2002.
I also have patches for some ftp problems related to incorrect download
format and wrong content length plus getting the file modification time
from the ftp server.
Villy