I have an Apache proxy to a custom Java app that returns status code 460 on a specific error condition. When this reaches the client, apache is incorrectly turning it into a 500 status code, although other ones (404, 403) get sent through correctly.

Here is my virtual host:

<VirtualHost *:80>
    ServerName api.acme.org
    ProxyPass / http://service.internal:10001/
    ProxyPassReverse / http://service.internal:10001/

And the log entry, which shows the correct code: - - [21/Nov/2010:23:20:17 +0000] "GET /session/abc123/touch HTTP/1.1" 460 1379

Any idea what is causing this?

Update: Here is the output to the headers from curl:

Direct to service:

# curl -I http://service.internal:10001/session/abc123/touch
HTTP/1.1 460
Content-length: 1388


# curl -O http://api.acme.org/session/abc123/touch
HTTP/1.1 500 Internal Server Error
Date: Mon, 22 Nov 2010 17:24:51 GMT
Content-length: 1388
Connection: close
Content-Type: text/plain; charset=UTF-8

Seems Apache has its own idea about what the error should be!

  • the same for code 452 from cgi script (no proxy) / Apache/2.2.22 (FreeBSD) mod_ssl/2.2.22 OpenSSL/0.9.8q DAV/2 – user132903 Aug 21 '12 at 12:03

The problem may be a bug in httpd. Fixed in 2.2.18.



On the contrary, it appears that Apache IS returning the correct error code. The log shows Apache returning 460, but your browser may be interpreting it differently (because 460 is not defined in an RFC). There's an easy way to check this; from a Linux machine (it could even be the server itself), try running the following:

curl -I http://service.internal:10001/session/abc123/touch

If this is returning 460, than it would appear to be something to do with the browsers (i.e., an unknown status code means a server error). If not, you may want to consider trying this WITHOUT using mod_proxy--i.e., by accessing the URL directly.

  • Thanks for this, I've updated the question with the responses from curl. Incidentally, I'm using 460 as a specific error to mean there is no such session. I was divided as to whether that should be 403, but I may implement HTTP auth as well and would like implementers to be able to quickly tell what is wrong. I didn't see anything appropriate in the 4XX range for this. – gub Nov 22 '10 at 17:27
  • The problem is, HTTP status codes aren't user defined. If you're defining this as a service, what you should be doing is having an HTTP status code (i.e., 403) as well as a user-defined status code, returned in the body of the response. – Andrew M. Nov 22 '10 at 19:43
  • I disagree: "HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes. Applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class". from the RFC available at: w3.org/Protocols/rfc2616/rfc2616-sec6.html – gub Nov 22 '10 at 22:45
  • I agree, but we're not dealing with your application anymore--we're dealing with mod_proxy and Apache. When you're dealing between things you control, its fine. But the RFC defines a set of status codes that MUST be acknowledged to be considered HTTP 1.1, which you can generally expect all applications--regardless of their source--to honor. – Andrew M. Nov 23 '10 at 3:58
  • 1
    Which isn't to say mod_proxy's behavior is correct... I am really curious as to why mod_proxy is manipulating the return code. I'll continue to research this. – Andrew M. Nov 23 '10 at 4:10

The mod_proxy don't know what status 460 mean and don't know how to react.

In contrast, when it sees status 200, it forward. When is sees 403, 404 and some other, it knows what to do.

  • I'm not sure it should matter, since RFC 2616 simply defines the 4XX range as "Client Error", and then defines a few specific ones. So the code isn't actually illegal, just unknown. – gub Nov 22 '10 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.