httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40029] mod_proxy should interoperate with RPC over HTTP
Date Fri, 16 Jul 2010 19:47:00 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=40029

--- Comment #17 from Graham Mainwaring <graham@mhn.org> 2010-07-16 15:46:57 EDT ---
I don't think it's HTTP 1.1 abuse. I can't find anything in RFC2068 that speaks
to this point one way or the other. I don't think it's required for mod_proxy
to implement this, but it certainly would not be RFC-violating to do so.

Suppose a back-end server sends a response with content-length: 1000 but only
sends 100 bytes. In that case mod_proxy transmits the 100 bytes to the
requestor and waits for further data.

But if the incoming request has content-length: 1000 but only sends 100 bytes,
mod_proxy just sits there. Why not open the request to the back-end right away?
It would improve performance even on regular GET requests, because you're
making use of time that would otherwise be wasted on network latency to get the
back-end connection open, which means you'll be able to generate a response
that much faster. If you have all the HTTP headers and part of the request
data, what's the benefit in *not* starting the connection to the back-end,
since you know you're going to need it?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message