Setting HTTP results code vs. HTTP type View as Markdown

Replying to a 1.0 request with a 1.1 response is perfectly fine.
It is the default for a fresh Apache install on a request for a
simple static file, for example.

-Rasmus

Christian Schneider wrote:

Hi all,
I ran into the following problem I would like to get an opinion on: We
noticed that our website returns a HTTP/1.1 chunked response even when
the request was a HTTP/1.0 request (e.g. php file_get_contents).

What happens:

• Wordpress (wrongly) set the result code with a hardcoded
  @header("HTTP/1.1 $header $text", true, $header);
• PHP 5.2.1 (IMHO wrongly) patches the protocol in
  sapi/apache2handler/sapi_apache2.c function
  php_apache_sapi_send_headers, probably because "force-response-1.1" does
  not exist (at least not in any production version):
  ctx->r->proto_num = 1000 + (sline[7]-'0');
• Apache thinks the request was 1.1 and under some circumstances decides
  to switch to Transfer-Encoding chunked.

I think the following should be done:

• Ask Wordpress to use $_SERVER['SERVER_PROTOCOL'] when available
  instead of a hardcoded HTTP/1.1 (I'll do that)
• Update the PHP header() documentation to mention this. I was also
  thinking that supporting/documenting header(null, true, 404); or the
  like would be nice for people who only want to set the return code and
  leave the HTTP type unchanged.
• Maybe change php_apache_sapi_send_headers to not mess with proto_num.
  This make it impossible to force the response to HTTP/1.1 but I don't
  think that should be done anyway as the client might not expect it. For
  the same reason I think the line
  apr_table_set(ctx->r->subprocess_env, "force-response-1.1", "true");
  should probably be removed as well...

Should I open a bug report on this?

Regards,

• Chris

• Update the PHP header() documentation to mention this. I was also
  thinking that supporting/documenting header(null, true, 404); or the
  like would be nice for people who only want to set the return code and
  leave the HTTP type unchanged.

I think this would bet he best approach, to give the PHP a users a
consistent way (consistent through all SAPIs) to set the http response
code without changing protocols.

Your problem only occurs with apache, as apache gives PHP the possibility to
change the HTTP protocol version. Other SAPIs, like my NSAPI one, cannot do
this because the protocol is the servers task and modules are not allowed to
change it in a wrong way.

The problem with setting the response code is:

• Some PHP scripts use header('Status: 301') to set response code. Problem
  here: This only works with CGI and Apache. The problem here is in PHP SAPI
  code: PHP only checks for ('HTTP/...') header strings and extracts status
  code and protocol version from it. The string 'HTTP/..' is never send to the
  SAPI. In case of 'Status: ', SAPI sends the header as a normal HTTP header
  to the webserver -> Apache maps this, CGI also because specs want this.

• Some scripts use header('HTTP/1.0 301 Moved Permanently'). Problem here:
  You must supply a HTTP version (this seems to be a problem in Apache), and
  you must supply the textual representation (but most/all? SAPIs ignore the
  textual representation). So header('HTTP/1.0 301 X') would be OK.

What we need is:

1. a consistent parsing of header() inputs before sending to the underlying
   SAPI. This means also parsing for 'Status: XXX' and setting the status code.
   The later SAPI then will generate the correct parameters to be sent to the
   server (in case of CGI it will "regenerate" a Status:-header).

2. a function to simply set the status code without changing anything other.

1. supplies such a method with 'Status: 301' if it is correctly implemented.

If nobody is against it I would try to implement a consistent header parsing
for SAPI...