You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2013/10/18 16:48:07 UTC

[Bug 55669] New: Mod_Cache caching 503 Errros

https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

            Bug ID: 55669
           Summary: Mod_Cache caching 503 Errros
           Product: Apache httpd-2
           Version: 2.4.6
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_cache
          Assignee: bugs@httpd.apache.org
          Reporter: tschmidty@yahoo.com

I am seeing an issue where apache 2.4.6 acting as a reverse proxy is caching
503 error messages which I don't understand at all. The proxy is a simple
proxypass directive, the backend server is apache proxying to an oracle ucm
instance. When I hit the proxy while both apaches are running but not the ucm
instance, I get a 503 response (expected). Apache is appropriately serving
stale content, but when that content expires (or I remove the cached content)
then apache caches the 503 response and will serve it even after the server is
back up. 

Here is the relevant part of the log

[Thu Oct 17 21:29:15.038716 2013] [proxy:debug] [pid 27382] proxy_util.c(2194):
[client 192.168.252.52:39745] AH00947: connected / to MYBACKENDSERVER
[Thu Oct 17 21:29:47.062046 2013] [proxy_http:trace3] [pid 27382]
mod_proxy_http.c(1403): [client 192.168.252.52:39745] Status from backend: 503
[Thu Oct 17 21:29:47.062103 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1086): [client 192.168.252.52:39745] Headers received from
backend:
[Thu Oct 17 21:29:47.062137 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Date: Thu, 17 Oct 2013
21:29:18 GMT
[Thu Oct 17 21:29:47.062245 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Server: Apache
[Thu Oct 17 21:29:47.062266 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Content-Type: text/html
[Thu Oct 17 21:29:47.062283 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Cache-Control: public
[Thu Oct 17 21:29:47.062299 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Expires: Thu, 17 Oct 2013
21:44:18 GMT
[Thu Oct 17 21:29:47.062319 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Vary: Accept-Encoding
[Thu Oct 17 21:29:47.062336 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Content-Length: 237
[Thu Oct 17 21:29:47.062352 2013] [proxy_http:trace4] [pid 27382]
mod_proxy_http.c(1088): [client 192.168.252.52:39745] Connection: close
[Thu Oct 17 21:29:47.062389 2013] [proxy_http:trace3] [pid 27382]
mod_proxy_http.c(1654): [client 192.168.252.52:39745] start body send
[Thu Oct 17 21:29:47.063336 2013] [deflate:debug] [pid 27382]
mod_deflate.c(764): [client 192.168.252.52:39745] AH01384: Zlib: Compressed 237
to 177 : URL /
[Thu Oct 17 21:29:47.063450 2013] [cache:debug] [pid 27382] mod_cache.c(1326):
[client 192.168.252.52:39745] AH00769: cache: Caching url: /
[Thu Oct 17 21:29:47.063515 2013] [cache:debug] [pid 27382] mod_cache.c(1332):
[client 192.168.252.52:39745] AH00770: cache: Removing CACHE_REMOVE_URL filter.
[Thu Oct 17 21:29:47.063657 2013] [http:trace3] [pid 27382]
http_filters.c(963): [client 192.168.252.52:39745] Response sent with status
503, headers:
[Thu Oct 17 21:29:47.063683 2013] [http:trace5] [pid 27382]
http_filters.c(970): [client 192.168.252.52:39745]   Date: Thu, 17 Oct 2013
21:29:18 GMT
[Thu Oct 17 21:29:47.063694 2013] [http:trace5] [pid 27382]
http_filters.c(973): [client 192.168.252.52:39745]   Server: Apache
[Thu Oct 17 21:29:47.063709 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Content-Type: text/html
[Thu Oct 17 21:29:47.063721 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Cache-Control:
public,max-age=900
[Thu Oct 17 21:29:47.063733 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Vary: Accept-Encoding
[Thu Oct 17 21:29:47.063744 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Content-Encoding: gzip
[Thu Oct 17 21:29:47.063755 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Connection: close
[Thu Oct 17 21:29:47.063766 2013] [http:trace4] [pid 27382]
http_filters.c(806): [client 192.168.252.52:39745]   Transfer-Encoding: chunked
[Thu Oct 17 21:29:47.064575 2013] [cache_disk:debug] [pid 27382]
mod_cache_disk.c(1349): [client 192.168.252.52:39745] AH00737: commit_entity:
Headers and body for URL http://www.nature.org:80/? cached.
[Thu Oct 17 21:29:47.064644 2013] [proxy_http:trace2] [pid 27382]
mod_proxy_http.c(1793): [client 192.168.252.52:39745] end body send

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Yann Ylavic <yl...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ylavic.dev@gmail.com

--- Comment #18 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Tod Schmidt from comment #17)
> This is still a problem with 2.4.10
> 
> The problem is not that we are adding headers it is that it is still caching
> it even without any headers that would allow it. Here are logs from two
> responses, the first it gets a 503 and caches it, the second it serves that
> bad content.

It is not clear whether mod_expires is involved in this scenario, it isn't
right?

> 
> [Thu Nov 20 17:52:42.184507 2014] [proxy_http:trace3] [pid 4506]
> mod_proxy_http.c(1420): [client 10.3.0.203:33820] Status from backend: 503
> [Thu Nov 20 17:52:42.184557 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1103): [client 10.3.0.203:33820] Headers received from
> backend:
> [Thu Nov 20 17:52:42.184578 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1105): [client 10.3.0.203:33820] Date: Thu, 20 Nov 2014
> 17:52:10 GMT
> [Thu Nov 20 17:52:42.184605 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1105): [client 10.3.0.203:33820] Server: Apache
> [Thu Nov 20 17:52:42.184623 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1105): [client 10.3.0.203:33820] Content-Type: text/html
> [Thu Nov 20 17:52:42.184640 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1105): [client 10.3.0.203:33820] Content-Length: 237
> [Thu Nov 20 17:52:42.184657 2014] [proxy_http:trace4] [pid 4506]
> mod_proxy_http.c(1105): [client 10.3.0.203:33820] Connection: close

So, no Cache-Control/Expires header sent by the backend.


> [Thu Nov 20 17:52:42.184698 2014] [proxy_http:trace3] [pid 4506]
> mod_proxy_http.c(1671): [client 10.3.0.203:33820] start body send
> [Thu Nov 20 17:52:42.185448 2014] [proxy:debug] [pid 4506]
> proxy_util.c(2146): AH00943: http: has released connection for
> (consumption1.tnc.org)
> [Thu Nov 20 17:52:42.185553 2014] [headers:trace2] [pid 4506]
> mod_headers.c(874): AH01502: headers: ap_headers_output_filter()

What is(are) mod_headers action(s) here?

> [Thu Nov 20 17:52:42.186002 2014] [cache:debug] [pid 4506]
> mod_cache.c(1330): [client 10.3.0.203:33820] AH00769: cache: Caching url: /
> [Thu Nov 20 17:52:42.186018 2014] [cache:debug] [pid 4506]
> mod_cache.c(1336): [client 10.3.0.203:33820] AH00770: cache: Removing
> CACHE_REMOVE_URL filter.
> [Thu Nov 20 17:52:42.186445 2014] [http:trace3] [pid 4506]
> http_filters.c(1008): [client 10.3.0.203:33820] Response sent with status
> 503, headers:
> [Thu Nov 20 17:52:42.186460 2014] [http:trace5] [pid 4506]
> http_filters.c(1015): [client 10.3.0.203:33820]   Date: Thu, 20 Nov 2014
> 17:52:10 GMT
> [Thu Nov 20 17:52:42.186472 2014] [http:trace5] [pid 4506]
> http_filters.c(1018): [client 10.3.0.203:33820]   Server: Apache
> [Thu Nov 20 17:52:42.186486 2014] [http:trace4] [pid 4506]
> http_filters.c(837): [client 10.3.0.203:33820]   Content-Type: text/html
> [Thu Nov 20 17:52:42.186498 2014] [http:trace4] [pid 4506]
> http_filters.c(837): [client 10.3.0.203:33820]   Content-Length: 237
> [Thu Nov 20 17:52:42.186510 2014] [http:trace4] [pid 4506]
> http_filters.c(837): [client 10.3.0.203:33820]   Cache-Control:
> public,max-age=1800

Where does this Cache-Control come from?
It makes the response cacheable.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Christophe JAILLET <ch...@wanadoo.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Christophe JAILLET <ch...@wanadoo.fr> ---
Fixed and released in 2.4.10

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #12 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Edward Lu from comment #7)
> Created attachment 31472 [details]
> Add ExpiresAllow directive to mod_expires

Wouldn't using a regexp be "easier" when many status codes are concerned?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #10 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Eric Covener from comment #9)
> > 
> > The insert_filter hook is run at the begining of ap_invoke_handler(), before
> > any error is set (either by the httpd or the backend).
> > 
> I think the old code only traps the error filter path
> 

The new code still does, though later.

> > This code makes no sense here, I think it should be moved to the output
> > filter itself, like in the attached patch.
> 
> I worry a bit about default behavior change on this one for backport,
> 304/301 for example

3xx are not caught by ap_is_HTTP_ERROR, only 4xx and 5xx.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #7 from Edward Lu <Ch...@gmail.com> ---
Created attachment 31472
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31472&action=edit
Add ExpiresAllow directive to mod_expires

It looks like this is happening only when something external to Apache is
returning an error code. This code, inside expires_insert_filter(), isn't
getting run:

    /* Don't add Expires headers to errors */
    if (ap_is_HTTP_ERROR(r->status)) {
        return;
    }

It probably has something to do with the error path for processing. Attached is
a patch that adds a directive allowing you to specify specific return codes
that mod_expires will process. It seems like something should also be done to
cleanup the code that's already there, though.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #5 from abiacco@formatdynamics.com ---
I can confirm this in 2.2.26. I am having 400 errors cached in a proxied URL
space in which i was having Apache apply CC/Expire headers.

I don't think we should be doing this, unless there is a way for us to NOT set
the CC/Expire headers based on response status.

Anthony J. Biacco

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Tod Schmidt <ts...@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #19 from Tod Schmidt <ts...@yahoo.com> ---
Argh, you are exactly right (of course). Sorry, was a long day. We did use
expires but had changed it to set the cache-control using the headers module so
we could set some other cache-control values as well. So expires is never
called in this case although it does apply for the other users on this thread. 

In my case, I suppose the workaround is the way to go. The confusing thing for
me was just not understanding that the headers were being applied on the proxy
server before the cache/no-cache decision was made.

So something like this:

Header set Cache-Control public,max-age=1800 "expr=%{REQUEST_STATUS} == '200'"

or 

Header set Cache-Control public,max-age=1800 "expr=%{REQUEST_STATUS} != '503'"

Would work in my situation. Thanks for your response and sorry to have
erroneously reopened this.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Mike Rumph <mi...@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Mod_Cache caching 503       |Mod_Cache caching 503
                   |Errros                      |Errors

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #3 from Graham Leggett <mi...@sharp.fm> ---
HTTP/1.1 allows the caching of 503 responses if the 503 response explicitly
states it is cacheable. This is expected behaviour of a cache. Can you clarify
what Cache-Control and/or Expires headers are included with your 503 response?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #6 from Asif Mushtaq <am...@etilizepak.com> ---
Hello, we are observing similar behavior with our apache 2.2.23 deployment
using mod_disk_cache. We are using apache to load balance and cache images from
backend tomcat servers. The issues is that if someone visits a URL which has
not yet been published hence resulting in a "404 Not Found" response, these
responses are getting cached also. Needless to say this causes issues when the
actual content is published later because the frontend proxy continues to serve
out cached "404 Not Found" response. We need to have a way to selectively
cache/not cache content based on response codes. Below is the relevant config
snippet.

<VirtualHost *:8080>                      

    ## Apache Load Balancing configuration
    <Proxy balancer://image-origin/>      
        BalancerMember http://oc1.etilize.com
        BalancerMember http://oc3.etilize.com
        ProxySet lbmethod=bybusyness         
        Order allow,deny                     
        Allow from env=allow_request                              
        Deny  from env=crawler                                    
        allow from all                                            
        #Expiry settings                                          
        ExpiresActive On                                          
        ExpiresDefault "access plus 15 days"                      

    </Proxy>                                                      

    ProxyPass / balancer://image-origin/
    ProxyPassReverse / balancer://image-origin/

    ## Apache Caching Configuration
    <IfModule mod_cache.c>         
        <IfModule mod_disk_cache.c>
            CacheEnable disk /       
            CacheRoot "/ebs/cache"
            CacheDirLength 1      
            CacheDirLevels 2
            CacheMaxFileSize 5000000
        </IfModule>
    </IfModule>

</VirtualHost>

Thanks,

Asif Mushtaq

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #14 from Yann Ylavic <yl...@gmail.com> ---
Commited in r1584430, proposed for backport to 2.4.x.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #11 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Yann Ylavic from comment #10)
> (In reply to Eric Covener from comment #9)
> > I think the old code only traps the error filter path
> The new code still does, though later.
We could also let the old code there, the new code would only catch the other
cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #15 from Edward Lu <Ch...@gmail.com> ---
(In reply to Yann Ylavic from comment #12)
> (In reply to Edward Lu from comment #7)
> > Created attachment 31472 [details]
> > Add ExpiresAllow directive to mod_expires
> 
> Wouldn't using a regexp be "easier" when many status codes are concerned?

That's probably true. I was going for ease of understanding, but the syntax
could probably get verbose quick. Either way, good to see that there was an
easier solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #1 from Tod Schmidt <ts...@yahoo.com> ---
Looking at the RFC does not seem to explicitly state that a 503 cannot be
cached.

   A response received with a status code of 200, 203, 206, 300, 301 or
   410 MAY be stored by a cache and used in reply to a subsequent
   request, subject to the expiration mechanism, unless a cache-control
   directive prohibits caching. However, a cache that does not support
   the Range and Content-Range headers MUST NOT cache 206 (Partial
   Content) responses.

   A response received with any other status code (e.g. status codes 302
   and 307) MUST NOT be returned in a reply to a subsequent request
   unless there are cache-control directives or another header(s) that
   explicitly allow it. For example, these include the following: an
   Expires header (section 14.21); a "max-age", "s-maxage",  "must-
   revalidate", "proxy-revalidate", "public" or "private" cache-control
   directive (section 14.9).

But I am not returning an expire or cache-control header and it is sill getting
cached.

Response from backend server
* About to connect() to 192.168.252.160 port 80 (#0)
*   Trying 192.168.252.160... connected
* Connected to 192.168.252.160 (192.168.252.160) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 192.168.252.160
> Accept: */*
>
< HTTP/1.1 503 Service Temporarily Unavailable
< Date: Fri, 25 Oct 2013 14:28:21 GMT
< Server: Apache
< Content-Type: text/html
< Content-Length: 237
< Connection: close
<
<HTML>
<HEAD>
<TITLE>Weblogic Bridge Message
</TITLE>
</HEAD>
 <BODY>
<H2>Failure of server APACHE bridge:</H2><P>
<hr>No backend server available for connection: timed out after 10 seconds or
idempotent set to OFF.
<hr> </BODY>
</HTML>

Response from Proxy server

* About to connect() to 192.168.252.211 port 80 (#0)
*   Trying 192.168.252.211... connected
* Connected to 192.168.252.211 (192.168.252.211) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Host: www.nature.org
>
< HTTP/1.1 503 Service Temporarily Unavailable
< Date: Fri, 25 Oct 2013 14:28:50 GMT
< Server: Apache
< Content-Type: text/html
< Cache-Control: public,max-age=900
< Vary: Accept-Encoding
< Content-Length: 237
< Connection: close
<
<HTML>
<HEAD>
<TITLE>Weblogic Bridge Message
</TITLE>
</HEAD>
 <BODY>
<H2>Failure of server APACHE bridge:</H2><P>
<hr>No backend server available for connection: timed out after 30 seconds or
idempotent set to OFF.
<hr> </BODY>
</HTML>

Subsequent response from proxy, note that it now has a 'Age:' header indicating
it is serverd from cache.

* About to connect() to 192.168.252.211 port 80 (#0)
*   Trying 192.168.252.211... connected
* Connected to 192.168.252.211 (192.168.252.211) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Host: www.nature.org
>
< HTTP/1.1 503 Service Unavailable
< Date: Fri, 25 Oct 2013 14:30:21 GMT
< Server: Apache
< Vary: Accept-Encoding
< Content-Length: 237
< Age: 123
< Connection: close
< Content-Type: text/html
<
<HTML>
<HEAD>
<TITLE>Weblogic Bridge Message
</TITLE>
</HEAD>
 <BODY>
<H2>Failure of server APACHE bridge:</H2><P>
<hr>No backend server available for connection: timed out after 30 seconds or
idempotent set to OFF.
<hr> </BODY>
</HTML>

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Tod Schmidt <ts...@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschmidty@yahoo.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #13 from Eric Covener <co...@gmail.com> ---
> 3xx are not caught by ap_is_HTTP_ERROR, only 4xx and 5xx.

Good point, +1. We can always do something more if people want to force
mod_expires in the future.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #9 from Eric Covener <co...@gmail.com> ---

> 
> The insert_filter hook is run at the begining of ap_invoke_handler(), before
> any error is set (either by the httpd or the backend).
> 
I think the old code only traps the error filter path

> This code makes no sense here, I think it should be moved to the output
> filter itself, like in the attached patch.

I worry a bit about default behavior change on this one for backport, 304/301
for example

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #4 from Mike Rumph <mi...@oracle.com> ---
Hello Graham,

If you are referring to my setup, here is the response I get:

    - $ curl -v http://localhost:8080/ 
* About to connect() to localhost port 8080
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8080
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 503 Service Unavailable
< Date: Wed, 13 Nov 2013 20:17:30 GMT
< Server: Apache/2.4.7-dev (Unix)
< Content-Length: 299
< Cache-Control: max-age=600
< Expires: Wed, 13 Nov 2013 20:22:23 GMT
< Age: 307
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Unavailable</title>
</head><body>
<h1>Service Unavailable</h1>
<p>The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.</p>
</body></html>
* Closing connection #0

After the max-age expires, a normal response is returned.

So I agree with you that this is in agreement with RFC 2616 section 13.4.
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4 

But my setup is only an attempt to reproduce the bug report.
Tod's results may be different.

The only error I see at this point is in the wording of the documentation at
the following location:
- http://httpd.apache.org/docs/2.4/caching.html#http-caching 
- "What Can be Cached?
  - 2. The response must have a HTTP status code of 200, 203, 300, 301 or 410."

This wording is not consistent with the last paragraph of RFC 2616 section
13.4.
- "A response received with any other status code (e.g. status codes 302 and
307) MUST NOT be returned in a reply to a subsequent request unless there are
cache-control directives or another header(s) that explicitly allow it."

Thanks,

Mike Rumph

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Mike Rumph <mi...@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #2 from Mike Rumph <mi...@oracle.com> ---
Hello Tod,

I have been able to duplicate your caching of 503 responses by setting up 3
layers of Apache httpd servers.
- a proxy server, a backend server and an up/down server.

In the proxy server configuration I have the follow caching directives:

CacheRoot /home/user/apache24/proxy
CacheEnable disk /
ExpiresActive On
ExpiresDefault "access plus 10 minutes"

With the up/down server down.
I get the 503 response from the proxy server.
The response contains Cache-Control: max-age=600 and Expires: headers.
Subsequent responses in addition have Age: headers.

Now with the up/down server up.
The 503 responses continue until the Age would exceed the max-age.
After that a proper HTML page is received.

Are you receiving any responses with the server up where Age exceeds max-age?
And are you using any caching directives in your proxy server configuration?

Thanks,

Mike Rumph

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

Tod Schmidt <ts...@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #17 from Tod Schmidt <ts...@yahoo.com> ---
This is still a problem with 2.4.10

The problem is not that we are adding headers it is that it is still caching it
even without any headers that would allow it. Here are logs from two responses,
the first it gets a 503 and caches it, the second it serves that bad content.

[Thu Nov 20 17:52:42.184507 2014] [proxy_http:trace3] [pid 4506]
mod_proxy_http.c(1420): [client 10.3.0.203:33820] Status from backend: 503
[Thu Nov 20 17:52:42.184557 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1103): [client 10.3.0.203:33820] Headers received from
backend:
[Thu Nov 20 17:52:42.184578 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1105): [client 10.3.0.203:33820] Date: Thu, 20 Nov 2014
17:52:10 GMT
[Thu Nov 20 17:52:42.184605 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1105): [client 10.3.0.203:33820] Server: Apache
[Thu Nov 20 17:52:42.184623 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1105): [client 10.3.0.203:33820] Content-Type: text/html
[Thu Nov 20 17:52:42.184640 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1105): [client 10.3.0.203:33820] Content-Length: 237
[Thu Nov 20 17:52:42.184657 2014] [proxy_http:trace4] [pid 4506]
mod_proxy_http.c(1105): [client 10.3.0.203:33820] Connection: close
[Thu Nov 20 17:52:42.184698 2014] [proxy_http:trace3] [pid 4506]
mod_proxy_http.c(1671): [client 10.3.0.203:33820] start body send
[Thu Nov 20 17:52:42.185448 2014] [proxy:debug] [pid 4506] proxy_util.c(2146):
AH00943: http: has released connection for (consumption1.tnc.org)
[Thu Nov 20 17:52:42.185553 2014] [headers:trace2] [pid 4506]
mod_headers.c(874): AH01502: headers: ap_headers_output_filter()
[Thu Nov 20 17:52:42.186002 2014] [cache:debug] [pid 4506] mod_cache.c(1330):
[client 10.3.0.203:33820] AH00769: cache: Caching url: /
[Thu Nov 20 17:52:42.186018 2014] [cache:debug] [pid 4506] mod_cache.c(1336):
[client 10.3.0.203:33820] AH00770: cache: Removing CACHE_REMOVE_URL filter.
[Thu Nov 20 17:52:42.186445 2014] [http:trace3] [pid 4506]
http_filters.c(1008): [client 10.3.0.203:33820] Response sent with status 503,
headers:
[Thu Nov 20 17:52:42.186460 2014] [http:trace5] [pid 4506]
http_filters.c(1015): [client 10.3.0.203:33820]   Date: Thu, 20 Nov 2014
17:52:10 GMT
[Thu Nov 20 17:52:42.186472 2014] [http:trace5] [pid 4506]
http_filters.c(1018): [client 10.3.0.203:33820]   Server: Apache
[Thu Nov 20 17:52:42.186486 2014] [http:trace4] [pid 4506] http_filters.c(837):
[client 10.3.0.203:33820]   Content-Type: text/html
[Thu Nov 20 17:52:42.186498 2014] [http:trace4] [pid 4506] http_filters.c(837):
[client 10.3.0.203:33820]   Content-Length: 237
[Thu Nov 20 17:52:42.186510 2014] [http:trace4] [pid 4506] http_filters.c(837):
[client 10.3.0.203:33820]   Cache-Control: public,max-age=1800
[Thu Nov 20 17:52:42.186522 2014] [http:trace4] [pid 4506] http_filters.c(837):
[client 10.3.0.203:33820]   Connection: close
[Thu Nov 20 17:52:42.188022 2014] [cache_disk:debug] [pid 4506]
mod_cache_disk.c(1350): [client 10.3.0.203:33820] AH00737: commit_entity:
Headers and body for URL http://www.nature.org:80/? cached.
[Thu Nov 20 17:52:42.188105 2014] [proxy_http:trace2] [pid 4506]
mod_proxy_http.c(1810): [client 10.3.0.203:33820] end body send
[Thu Nov 20 17:52:42.188129 2014] [core:trace6] [pid 4506] core_filters.c(527):
[client 10.3.0.203:33820] core_output_filter: flushing because of FLUSH bucket
[Thu Nov 20 17:52:42.188212 2014] [log_debug:trace4] [pid 4506]
util_expr_eval.c(822): [client 10.3.0.203:33820] Evaluation of string
expression from /usr/local/apache2/conf.d/local-11g.conf:54 gave: Status
(cache): 503
[Thu Nov 20 17:52:42.188227 2014] [log_debug:info] [pid 4506] [client
10.3.0.203:33820] Status (cache): 503 (log_transaction hook,
/usr/local/apache2/conf.d/local-11g.conf:54)
[Thu Nov 20 17:52:42.188622 2014] [core:trace6] [pid 4506] core_filters.c(527):
[client 10.3.0.203:33820] core_output_filter: flushing because of FLUSH bucket




[Thu Nov 20 17:53:21.091484 2014] [core:trace5] [pid 4505] protocol.c(618):
[client 10.3.0.203:33822] Request received from client: GET / HTTP/1.1
[Thu Nov 20 17:53:21.091710 2014] [http:trace4] [pid 4505] http_request.c(301):
[client 10.3.0.203:33822] Headers received from client:
[Thu Nov 20 17:53:21.091728 2014] [http:trace4] [pid 4505] http_request.c(305):
[client 10.3.0.203:33822]   User-Agent: curl/7.15.5 (i386-redhat-linux-gnu)
libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
[Thu Nov 20 17:53:21.091764 2014] [http:trace4] [pid 4505] http_request.c(305):
[client 10.3.0.203:33822]   Accept: */*
[Thu Nov 20 17:53:21.091777 2014] [http:trace4] [pid 4505] http_request.c(305):
[client 10.3.0.203:33822]   host: www.nature.org
[Thu Nov 20 17:53:21.091809 2014] [cache:debug] [pid 4505]
cache_storage.c(664): [client 10.3.0.203:33822] AH00698: cache: Key for entity
/?(null) is http://www.nature.org:80/?
[Thu Nov 20 17:53:21.091935 2014] [cache_disk:debug] [pid 4505]
mod_cache_disk.c(572): [client 10.3.0.203:33822] AH00709: Recalled cached URL
info header http://www.nature.org:80/?
[Thu Nov 20 17:53:21.091963 2014] [cache_disk:debug] [pid 4505]
mod_cache_disk.c(885): [client 10.3.0.203:33822] AH00720: Recalled headers for
URL http://www.nature.org:80/?
[Thu Nov 20 17:53:21.091995 2014] [log_debug:trace4] [pid 4505]
util_expr_eval.c(822): [client 10.3.0.203:33822] Evaluation of string
expression from /usr/local/apache2/conf.d/local-11g.conf:54 gave: Status
(cache): 200
[Thu Nov 20 17:53:21.092010 2014] [log_debug:info] [pid 4505] [client
10.3.0.203:33822] Status (cache): 200 (insert_filter hook,
/usr/local/apache2/conf.d/local-11g.conf:54)
[Thu Nov 20 17:53:21.092032 2014] [cache:debug] [pid 4505] mod_cache.c(652):
[client 10.3.0.203:33822] AH00763: cache: running CACHE_OUT filter
[Thu Nov 20 17:53:21.092048 2014] [cache:debug] [pid 4505] mod_cache.c(681):
[client 10.3.0.203:33822] AH00764: cache: serving /
[Thu Nov 20 17:53:21.092075 2014] [http:trace3] [pid 4505]
http_filters.c(1008): [client 10.3.0.203:33822] Response sent with status 503,
headers:
[Thu Nov 20 17:53:21.092088 2014] [http:trace5] [pid 4505]
http_filters.c(1015): [client 10.3.0.203:33822]   Date: Thu, 20 Nov 2014
17:53:21 GMT
[Thu Nov 20 17:53:21.092100 2014] [http:trace5] [pid 4505]
http_filters.c(1018): [client 10.3.0.203:33822]   Server: Apache
[Thu Nov 20 17:53:21.092115 2014] [http:trace4] [pid 4505] http_filters.c(837):
[client 10.3.0.203:33822]   Content-Length: 237
[Thu Nov 20 17:53:21.092127 2014] [http:trace4] [pid 4505] http_filters.c(837):
[client 10.3.0.203:33822]   Cache-Control: public,max-age=1800
[Thu Nov 20 17:53:21.092138 2014] [http:trace4] [pid 4505] http_filters.c(837):
[client 10.3.0.203:33822]   Age: 103
[Thu Nov 20 17:53:21.092150 2014] [http:trace4] [pid 4505] http_filters.c(837):
[client 10.3.0.203:33822]   Connection: close
[Thu Nov 20 17:53:21.092161 2014] [http:trace4] [pid 4505] http_filters.c(837):
[client 10.3.0.203:33822]   Content-Type: text/html
[Thu Nov 20 17:53:21.092264 2014] [core:trace6] [pid 4505] core_filters.c(527):
[client 10.3.0.203:33822] core_output_filter: flushing because of FLUSH bucket
[Thu Nov 20 17:53:21.092477 2014] [log_debug:trace4] [pid 4505]
util_expr_eval.c(822): [client 10.3.0.203:33822] Evaluation of string
expression from /usr/local/apache2/conf.d/local-11g.conf:54 gave: Status
(cache): 503
[Thu Nov 20 17:53:21.092494 2014] [log_debug:info] [pid 4505] [client
10.3.0.203:33822] Status (cache): 503 (log_transaction hook,
/usr/local/apache2/conf.d/local-11g.conf:54)
[Thu Nov 20 17:53:21.092544 2014] [core:trace6] [pid 4505] core_filters.c(527):
[client 10.3.0.203:33822] core_output_filter: flushing because of FLUSH bucket

I even went so far as to add an unset for the headers

Header always unset Cache-Control "expr=%{REQUEST_STATUS} == '503'"

Which would presumably unset any headers and is after any other header
directives

[Thu Nov 20 18:46:31.413346 2014] [headers:trace4] [pid 5598]
util_expr_eval.c(837): [client 10.3.0.203:33825] Evaluation of expression from
/usr/local/apache2/conf.d/local-11g.conf:49 gave: 1

This seems to indicate that the header would have been removed but no luck

However, adding that expression as != to my existing header declaration does
work and appropriately does not cache.

Header set Cache-Control public,max-age=1800 "expr=%{REQUEST_STATUS} != '503'"

[Thu Nov 20 18:53:59.783143 2014] [headers:trace4] [pid 5635]
util_expr_eval.c(837): [client 10.3.0.203:33832] Evaluation of expression from
/usr/local/apache2/conf.d/local-11g.conf:49 gave: 1
[Thu Nov 20 18:53:59.783168 2014] [headers:trace4] [pid 5635]
util_expr_eval.c(837): [client 10.3.0.203:33832] Evaluation of expression from
/usr/local/apache2/conf.d/local-11g.conf:44 gave: 0
[Thu Nov 20 18:53:59.783213 2014] [cache:debug] [pid 5635] mod_cache.c(1212):
[client 10.3.0.203:33832] AH00768: cache: / not cached. Reason: Response status
503

So the code from ylavic does not seem to catch the error condition and still
adds the cache control headers. But using this as a workaround will do the job
for me and I can add conditions for the other errors with a regex but I don't
think this is fully resolved. I will keep an eye on this if there is a
different patch you would like me to test

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 55669] Mod_Cache caching 503 Errors

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55669

--- Comment #8 from Yann Ylavic <yl...@gmail.com> ---
Created attachment 31473
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31473&action=edit
Don't add Expires header on errors (really)

(In reply to Edward Lu from comment #7)
> It looks like this is happening only when something external to Apache is
> returning an error code. This code, inside expires_insert_filter(), isn't
> getting run:
> 
>     /* Don't add Expires headers to errors */
>     if (ap_is_HTTP_ERROR(r->status)) {
>         return;
>     }
> 

The insert_filter hook is run at the begining of ap_invoke_handler(), before
any error is set (either by the httpd or the backend).

This code makes no sense here, I think it should be moved to the output filter
itself, like in the attached patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org