I'm not sure if this is the right place to ask. Please refer me to the correct list otherwise.

I was wondering why Apache returns a status code 500 on unrecognized status codes. According to the RFCs (2616+7231, Section 6 - Response Status Codes), any unrecognized status code MUST be understood and treated as being equivalent to the x00 status
code of that class. E.g. receiving a status code 222, apache should return 200 instead of 500.

Does anyone know the rationale as to why Apache is not following the RFC?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.infosystems.www.servers.unix,
vikingforce.de <schmalowsky@gmail.com> wrote:

I'm not sure if this is the right place to ask. Please refer me to the correct list otherwise.

I was wondering why Apache returns a status code 500 on unrecognized status codes. According
to the RFCs (2616+7231, Section 6 - Response Status Codes), any unrecognized status code
MUST be understood and treated as being equivalent to the x00 status code of that class.
E.g. receiving a status code 222, apache should return 200 instead of 500.

Does anyone know the rationale as to why Apache is not following the RFC?

The MUST from Section 6 in 2616 refers to *clients*, not servers.

[...] HTTP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, 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, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.

And the MUST from Section 6 in 7231 also refers to *clients*, not servers.

[...] HTTP clients are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code.

For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a
representation that explains the status.

So what's the context of Apache receiving this error code? A local CGI?
That would NOT be a context in which Apache MUST accept the code.
Something else? Maybe an error.

My experience is that Apache, quite reasonably, refuses to accept
*locally generated* errors that it does not understand.

Elijah
------
who has tested this extensively with .htaccess error codes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 25, 2018 at 12:57:02 AM UTC+2, Eli the Bearded wrote:

In comp.infosystems.www.servers.unix,
vikingforce.de <schmalowsky@gmail.com> wrote:

I'm not sure if this is the right place to ask. Please refer me to the correct list otherwise.

I was wondering why Apache returns a status code 500 on unrecognized status codes. According
to the RFCs (2616+7231, Section 6 - Response Status Codes), any unrecognized status code
MUST be understood and treated as being equivalent to the x00 status code of that class.
E.g. receiving a status code 222, apache should return 200 instead of 500.

Does anyone know the rationale as to why Apache is not following the RFC?

The MUST from Section 6 in 2616 refers to *clients*, not servers.

[...] HTTP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, 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, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.

And the MUST from Section 6 in 7231 also refers to *clients*, not servers.

[...] HTTP clients are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code.

For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a
representation that explains the status.

So what's the context of Apache receiving this error code? A local CGI?
That would NOT be a context in which Apache MUST accept the code.
Something else? Maybe an error.

My experience is that Apache, quite reasonably, refuses to accept
*locally generated* errors that it does not understand.

Elijah
------
who has tested this extensively with .htaccess error codes

Apache, configured as reverse proxy, acts as client in this scenario. In my understanding, the sections outlined apply.

I've studied the source code, specifically the function `index_of_response' (modules/http/http_protocol.c) which returns 500 for every unknown status code.

Maybe I didn't read it right and this function is not called when Apache acts as client.

Even though, Apache COULD return a status code following Section 6 in 7231. Or just pass it through. I'm interested in the reason why it's not.


Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.infosystems.www.servers.unix,
vikingforce.de <schmalowsky@gmail.com> wrote:

Apache, configured as reverse proxy, acts as client in this scenario.
In my understanding, the sections outlined apply.

As a proxy, yes, I think Apache should be following that part of the
RFCs. But I don't have any insight into why it does not.

Even though, Apache COULD return a status code following Section 6 in
7231. Or just pass it through. I'm interested in the reason why it's
not.

My years of experience reading this group suggest you won't find an
answer here, sorry.

Elijah
------
it's been pretty quiet the last decade

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)