Stop hardcoding the HTTP protocol version

I think this is important to have, so we get away from hard coded HTTP protocol versions.

Here is a patch against today's HEAD.

Needs testing with various environments.

Changing title ...

Squid users also have problems with this. Its the cause of the random hex characters appearing at the top of error pages. There are several issues in the D5 queue about this already.

I don't think just using SERVER_PROTOCOL is sufficient. The page cache caches the response headers as well, so it will use the protocol version of the first user who requests the page. I see two solutions:

1. Just use HTTP/1.0 for error pages.
2. Modify the code to use the correct version on output.

While (2) is probably the best solution, it can be a bit tricky. I'm using (1) on all my D5 sites, i can live without HTTP/1.1 on error pages..

Note that SERVER_PROTOCOL contains whatever protocol version the user sends.

If a client sometime in the future makes an HTTP/2.0 request to an HTTP/1.1 server, the server should not claim support for HTTP/2.0 but rather respond with HTTP/1.1.

Perhaps the third parameter for header() can be used.

In Wordpress, the response is sent as either HTTP/1.0 or HTTP/1.1, depending on the request:
http://trac.wordpress.org/ticket/3886

Patch #1 need to be re-rolled.

New patch that eliminates the hard coded protocol.

I'm not sure this is exactly what is needed.

If I read it correctly, this means that drupal_http_request will send its requests via the SERVER_PROTOCOL of the user which is requesting the page. This is not always desired. For instance, say I have a client who is accessing a page with HTTP 1.0, but on that page I have to load some data from a web service, and I want to use HTTP 1.1 to make that request. With this patch, the request goes out as 1.0

Perhaps better is to add a $conf variable for outgoing HTTP requests and use this in drupal_http_request.

Best,
Jacob

drupal_http_request should stay HTTP 1.0. Here is a reroll.

Hi Damien,

Can you explain to me the rationale for your last statement? Defaulting to 1.0 is one thing, but I can't see any reason to hardcode it (or base outgoing request protocol versions on the incoming protocol version)

Best,
Jacob

Defaulting to 1.0 is one thing, but I can't see any reason to hardcode it (or base outgoing request protocol versions on the incoming protocol version)

The HTTP client in drupal_http_request() is not HTTP/1.1 compliant but only supports HTTP/1.0.

For instance, HTTP/1.1 compliant clients MUST support the chunked transfer encoding, but this is not supported by drupal_http_request(). So if Drupal claims HTTP/1.1 support in the request header, the server may return something that drupal_http_request() doesn't understand.

So it is correct to hardcode the version number for outgoing requests - at least until Drupal gets support for HTTP/1.1.

@c960657: thank you! I felt that our implementation was not HTTP/1.1 but I was unable to find a compelling argument.

There was also an hardcoded version in install.php. Also, we are ensuring that the SERVER_PROTOCOL is sane in the new drupal_initialize_variables().

The patch for install.php didn't make it for some reason.

Ah! Thanks for the explanation.

Still, is there someway I can hack around it? Even if it means doing something like:

if (!defined('DRUPAL_HTTP_VERSION')) {
define('DRUPAL_HTTP_VERSION','HTTP/1.1');
}

Because I think there are cases where even though the drupal_http_client doesn't support all 1.1 features, other systems might require it but not actually require those features, and for hackers like me, there are cases.

I guess I just wonder why we would want to hardcode anything. If nothing else, a constant or a $conf var eliminates the need for someone to then hack core / replicate the function. But yeah, I get your point, it shouldn't be 1.1 by default.

Best,
Jacob

@JacobSingh: drupal_http_request is a mess right now. There would be a lot of work to do on it to make it good. I don't want to cluter it more by adding a somewhat unneeded new feature.

I've committed this patch to CVS HEAD. We can still discuss Jacob's case separately. Hence, I'm not marking this 'fixed' yet.

Because I think there are cases where even though the drupal_http_client doesn't support all 1.1 features, other systems might require it but not actually require those features, and for hackers like me, there are cases.

That sounds like some rather exotic cases. Could you give some examples?

@JacobSingh: Any comments on #19?

re #19 - see: http://pajamadesign.com/2008/09/02/how-to-gzip-compression-between-drupa...

nginx does not support gzip unless it's HTTP 1.1