I use drupal+apache on backend and ngnix on frontend
Nginx request apache by HTTP/1.0 but apache response HTTP/1.1 using chunked
Therefore, I have trouble displaying some pages.
My solution to the problem - run this
find includes/ | xargs grep -ilE 'header[(]'\''HTTP/1.1' | xargs perl -pi -e 's#'\''HTTP/1.1 #\$_SERVER['\''SERVER_PROTOCOL'\''].'\'' #g;'
It is replace
drupal_set_header('HTTP/1.1 503 Service Unavailable');
to
drupal_set_header($_SERVER['SERVER_PROTOCOL'].' 503 Service Unavailable');
Comment | File | Size | Author |
---|---|---|---|
#30 | 208793-D6-http-protocol.patch | 3.93 KB | TR |
#25 | 208793-D6-http-protocol.patch | 3.94 KB | TR |
#15 | 208793-hardcoded-server-protocol-2.patch | 3.78 KB | Damien Tournoud |
#14 | 208793-hardcoded-server-protocol.patch | 3.33 KB | Damien Tournoud |
#9 | server-protocol_0.patch | 3.45 KB | Damien Tournoud |
Comments
Comment #1
kbahey CreditAttribution: kbahey commentedI 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.
Comment #2
kbahey CreditAttribution: kbahey commentedChanging title ...
Comment #3
Bart Jansens CreditAttribution: Bart Jansens commentedSquid 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..
Comment #4
c960657 CreditAttribution: c960657 commentedNote 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.
Comment #5
c960657 CreditAttribution: c960657 commentedIn Wordpress, the response is sent as either HTTP/1.0 or HTTP/1.1, depending on the request:
http://trac.wordpress.org/ticket/3886
Comment #6
lilou CreditAttribution: lilou commentedPatch #1 need to be re-rolled.
Comment #7
kbahey CreditAttribution: kbahey commentedNew patch that eliminates the hard coded protocol.
Comment #8
JacobSingh CreditAttribution: JacobSingh commentedI'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
Comment #9
Damien Tournoud CreditAttribution: Damien Tournoud commenteddrupal_http_request should stay HTTP 1.0. Here is a reroll.
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedComment #11
JacobSingh CreditAttribution: JacobSingh commentedHi 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
Comment #12
c960657 CreditAttribution: c960657 commentedThe 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.
Comment #13
Damien Tournoud CreditAttribution: Damien Tournoud commented@c960657: thank you! I felt that our implementation was not HTTP/1.1 but I was unable to find a compelling argument.
Comment #14
Damien Tournoud CreditAttribution: Damien Tournoud commentedThere was also an hardcoded version in install.php. Also, we are ensuring that the SERVER_PROTOCOL is sane in the new
drupal_initialize_variables()
.Comment #15
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe patch for install.php didn't make it for some reason.
Comment #16
JacobSingh CreditAttribution: JacobSingh commentedAh! 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
Comment #17
Damien Tournoud CreditAttribution: Damien Tournoud commented@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.
Comment #18
Dries CreditAttribution: Dries commentedI've committed this patch to CVS HEAD. We can still discuss Jacob's case separately. Hence, I'm not marking this 'fixed' yet.
Comment #19
c960657 CreditAttribution: c960657 commentedThat sounds like some rather exotic cases. Could you give some examples?
Comment #20
c960657 CreditAttribution: c960657 commented@JacobSingh: Any comments on #19?
Comment #21
pwolanin CreditAttribution: pwolanin commentedre #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
Comment #22
sun.core CreditAttribution: sun.core commentedReverting status.
Comment #23
TR CreditAttribution: TR commentedThis was never backported to Drupal 6. Should it be?
Comment #24
c960657 CreditAttribution: c960657 commentedYes, I think a backport would be appropriate.
Comment #25
TR CreditAttribution: TR commentedOK, here's a straight port to Drupal 6 of the patch from#15. Let's see what the testbot has to say about it.
Comment #26
pwolanin CreditAttribution: pwolanin commentedI don't think the bot tests D6 patches - it must have applied yours against D7, since you did not follow the naming convention.
Comment #27
TR CreditAttribution: TR commentedActually, if you look at the log, it did apply it against D6 and test it against D6. But since there are no test cases for core D6, the test results don't mean much other than showing the patch does apply and doesn't introduce any syntax errors.
What naming convention are you referring to? The one I know about says the opposite - that you DON'T end the patch name in -Dn unless you want the bot to ignore it. For example, if you uploaded patches for D7 and D8 into an 8.x issue you would suffix the D7 patch with -D7 to tell the bot not to test it. That's not the case here - this thread is a D6 thread so the bot assumes the patch is for D6 unless told otherwise.
Comment #28
c960657 CreditAttribution: c960657 commentedComment #29
Gábor HojtsyDrupal 6 code style requires different treatment for string concatenation.
Comment #30
TR CreditAttribution: TR commentedSame patch as in #25, but with the D6 code style for string concatenations. Setting back to RTBC, if that's the only objection.
Comment #31
protoplasm CreditAttribution: protoplasm commentedThank you! I'm running nginx proxy in front of apache on a big D6 site. 404's generated those strange numbers and I was at a loss for fixing it. Development server using windows/wamp and no proxy had no such issue. This patch fixed the issue. Thanks!
I'm just curious--could you just suppress the error message without reverting to the 1.0 header? I don't know much about this, so I'm sure it's something you already considered and dismissed as not viable.
Comment #32
Gábor HojtsyCommitted to Drupal 6, thanks.