Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: ap_get_status_line(int)
Message-Id: <3E849005-C37E-4ED0-9E97-5B948DF2418C@greenbytes.de>
Date: Thu, 3 Nov 2016 18:51:33 +0100
To: dev@httpd.apache.org
archived-at: Thu, 03 Nov 2016 17:51:52 -0000

Like to get your opinion:=20

ap_get_status_line(int) converts any status code it does not know into a =
500. This is fine for the use cases we had so far, although it can be =
discussed if it is a good idea, too strict or whatnot. But I do not want =
to go down that rathole...

My question is how httpd should handle unknown codes coming from an =
upstream server. Currently:
- mod_proxy_http sends it on (tested for intermediate responses)
- mod_proxy_http2 sends a 500 server error

The reason for this is that mod_proxy_http2 generates a status line =
using ap_get_status_line() while mod_proxy_http can parse that line from =
the upstream response.

So, we have different handling of status code acceptance in proxies =
responses for HTTP/1.x and HTTP/2. This should not be. Question is, do =
we need another function which returns NULL for such cases, so the =
caller can decide to give up or work around it?

-Stefan