Bug 13946

Can you specify where you think the problem is in the log you attached?

If you are concerned about the "no cache - add cache_in filter and DECLINE" part
of the message, that is perfectly normal. This simply indicates that the cache
handler has noticed that new, cacheable content is arriving. It inserts the
cache_in filter into the filter chain so that the caching code can store the new
content as it flows through, but it returns "declined" to indicate that the
cache handler didn't process the response.

I'm going to wait a few days for a clarification on this. If there isn't
something I've missed here then I'll go ahead and close this PR at that point.

Having received no response to the contrary, I have to assume that this was not
actually a problem after all. I'm closing it now. It can be re-opened if someone
disagrees.

Hi, sorry for the delay.
Well, the error is right here:
---
[Fri Oct 25 18:59:00 2002] [debug] proxy_http.c(221): proxy: HTTP connecting 
http://10.0.0.2/proxy:http://10.0.0.2/index.html to 10.0.0.2:80
---

it tries to get the URL http://10.0.0.2/proxy:http://10.0.0.2/index.html, 
generating errors. it only happens when using mod_proxy with mod_rewrite. it 
looks like mod_rewrite appends the "http://10.0.0.2/proxy:" string, in the 
example, but *only* when the document expires from the cache.

Does the server return an error to the client or does the server succeed in
retrieving and returning the page from the proxy machine? In other words, is it
just a logging issue or does it actually fail to retrieve the page after it expires?

I don't see a log entry indicating that the page isn't found, and the only entry
in the log from the cache code indicates that it is inserting the
cache_in_filter to handle the page returned from the proxy.

Thanks for any additional info you can provide.

in all these requests, the server returns an error to the client.

What is the error returned to the client and what error(s) get logged into the
server's error_log or access_log?

This seems to be a mod_cache bug

hi there,
the bug persists in httpd-2.0.44. Here is some piece of the error_log:

[Tue Jan 28 15:48:23 2003] [error] [client 200.164.36.73] proxy: URI cannot be 
parsed: http://xxx.com.brproxy:http//xxx.com.br/imagens/pix.gif returned 
by /imagens/pix.gif
[Tue Jan 28 15:48:23 2003] [error] [client 200.207.161.223] proxy: URI cannot 
be parsed: http://xxx.com.brproxy:http//xxx.com.br/beach/t3.jpg returned 
by /beach/t3.jpg, referer: http://xxx.com.br/beach/left.html
[Tue Jan 28 15:48:23 2003] [error] [client 200.191.233.186] proxy: URI cannot 
be parsed: http://yyy.com.brproxy:http//yyy.com.br/imagens/b.gif returned 
by /imagens/b.gif, referer: http://yyy.com.br/

another error:

access_log:
200.174.198.133 - - [28/Jan/2003:15:47:18 - 0200] "GET /js/video.js HTTP/1.1" 
400 498 "http://xxx.com.br/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"

error_log:
[Tue Jan 28 15:47:18 2003] [error] [client 200.174.198.133] proxy: URI cannot 
be parsed: http://xxx.com.brproxy:http//xxx.com.br/js/video.js returned 
by /js/video.js, referer: http://xxx.com.br/

It *only* happens with mod_rewrite with reverse proxy.

Created attachment 4670 [details]
Patch to solve the probem

A did attach a patch to solve this bug. It is caused when the mod_rewrite 
reprocess the request after mod_proxy return it.

Created attachment 4671 [details]
Patch fix, now generated by a diff -u

Let's not mark this as resolved/fixed until a fix is actually committed... 
otherwise the patch might get lost.  :)

Thanks,
Cliff

Is this fixed now or not? :-)

I'm currently looking into porting the old patch to the current code, verifying
the patch, and committing it to cvs. I am not convinced that this part of the
patch needs to be present since we aren't seeing "proxy:proxy:" which is what
this if statement would prevent...

@@ -2082,6 +2098,7 @@
             rewritelog(r, 2, "[per-dir %s] forcing proxy-throughput with %s",
                        perdir, r->filename);
         }
+        if (strncasecmp("proxy:",r->filename,6))
         r->filename = apr_pstrcat(r->pool, "proxy:", r->filename, NULL);
         return 1;
     }

Created attachment 7229 [details]
Updated version of Fabio's patch from above. (current 2.1-dev branch)

I have tested the updated patch and committed it to the Apache 2.1-dev branch. I
will submit it for a vote to backport to the 2.0-stable branch. Thank you for
your efforts in identifying and fixing this bug.

Perhaps I'm missing something... The provided config:

ProxyRequests Off
ProxyVia Full
ProxyTimeout 30
ProxyReceiveBufferSize 16384
ProxyMaxForwards 10
CacheEnable mem /
CacheDefaultExpire 10
CacheMaxExpire 30
CacheLastModifiedFactor 0.1
CacheMaxStreamingBuffer 65536 
MCacheSize 524288
MCacheMaxObjectCount 32768
MCacheMinObjectSize 1 
MCacheMaxObjectSize 100000
MCacheRemovalAlgorithm GDSF
RewriteEngine   on
RewriteRule     ^(.*)$     $1 [P,L]

creates an infinite loop (proxying to itself), doesn't it? Why is this useful?

updating PRs to add PatchAvailable keyword
For updated information on submitting patches, see
http://httpd.apache.org/dev/patches.html

Can you test this on 2.0.54? Lots of things in both proxy and cache have been
changed since this was last reported.

No activity after a very long time in NEEDINFO; assuming expired.