You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Andrew Ho <an...@tellme.com> on 2003/03/06 04:54:14 UTC
HTTP/1.1 requests get HTTP/1.1 responses even with downgrade-1.0
(Was: force-response-1.0 ignored for HTTP/1.1 requests)
Hello,
JS>The long answer: using downgrade-1.0 will, in fact, force Apache to treat
JS>the request as if it was HTTP/1.0. It will therefore use only HTTP/1.0
JS>features in the response. But it will still respond with HTTP/1.1 in the
JS>response line, since this just declares it as an HTTP/1.1 capable server;
JS>it doesn't mean the response itself uses HTTP/1.1 features.
Agreed on HTTP/1.1 declared in the response line; this is what RFC 2616
says should happen. However, I'm seeing behavior different from what you
just described. That is, with downgrade-1.0, I still see Apache respond
with HTTP/1.1 semantics.
On a freshly built Apache 1.3.27 server with downgrade-1.0 set to 1 via a
SetEnv command, I can issue this request:
GET /test.cgi HTTP/1.1
Host: www.example.com
Where test.cgi is just a CGI that prints out the string "OK":
#!/bin/sh
echo "Content-Type: text/plain"
echo
echo "OK"
Apache responds with chunked Transfer-Encoding and keeps the connection
open, clearly HTTP/1.1 behaviors:
HTTP/1.1 200 OK
Date: Thu, 06 Mar 2003 03:33:42 GMT
Server: Apache/1.3.27 (Unix)
Transfer-Encoding: chunked
Content-Type: text/plain
3
OK
0
JS>[This question seems more appropriate for the users list rather than
JS>the developers list.]
Well, I thought of this list because this seems like either a bug, or a
mismatch between the documentation and the actual behavior. I guess my
original subject line was wrong, though, and I've corrected it.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer 1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
----------------------------------------------------------------------
Re: HTTP/1.1 requests get HTTP/1.1 responses even with downgrade-1.0
(Was: force-response-1.0 ignored for HTTP/1.1 requests)
Posted by Andrew Ho <an...@tellme.com>.
Hello,
JT>I went through the same test this a.m. for a customer with some device
JT>that couldn't handle chunked response. For me, using BrowserMatch to
JT>set downgrade-1.0 eliminated the use of chunking in the response.
Interesting. I confirmed on my setup that this works (answers my HTTP/1.1
query with an HTTP/1.0 request) for all incoming requests:
BrowserMatch ^ downgrade-1.0
So I guess that is my workaround for the time being. But I'm still curious
why this presumed equivalent does not work for any incoming requests:
SetEnv downgrade-1.0 1
I browsed through mod_setenv_if.c and it sure looks to me like the
BrowserMatch command should be functionally equivalent to the SetEnv
command (including using 1 as the true value). Indeed, the documentation
at http://httpd.apache.org/docs/env.html#special states that downgrade-1.0
and friends are "invoked by defining environment variables, typically with
BrowserMatch, though SetEnv and PassEnv could also be used."
In src/main/http_request.c, the check for downgrade-1.on line 1218 just
checks that ap_table_get(r->subprocess_env, "downgrade-1.0") is true,
which it should be in both cases. If I print out the environment in the
test CGI being invoked, in both cases I see downgrade_1_0=1. But, when I
put in some debugging statements, I see that in the BrowserMatch case,
ap_table_get(r->subprocess_env, "downgrade-1.0") == 1, but in the SetEnv
case, that same statement returns NULL.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer 1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
----------------------------------------------------------------------
Re: HTTP/1.1 requests get HTTP/1.1 responses even with downgrade-1.0
(Was: force-response-1.0 ignored for HTTP/1.1 requests)
Posted by Jeff Trawick <tr...@attglobal.net>.
Andrew Ho wrote:
> Hello,
>
> JS>The long answer: using downgrade-1.0 will, in fact, force Apache to
> treat
> JS>the request as if it was HTTP/1.0. It will therefore use only HTTP/1.0
> JS>features in the response. But it will still respond with HTTP/1.1
> in the
> JS>response line, since this just declares it as an HTTP/1.1 capable
> server;
> JS>it doesn't mean the response itself uses HTTP/1.1 features.
>
> Agreed on HTTP/1.1 declared in the response line; this is what RFC 2616
> says should happen. However, I'm seeing behavior different from what you
> just described. That is, with downgrade-1.0, I still see Apache respond
> with HTTP/1.1 semantics.
>
> On a freshly built Apache 1.3.27 server with downgrade-1.0 set to 1 via a
> SetEnv command, I can issue this request:
>
> GET /test.cgi HTTP/1.1
> Host: www.example.com
>
> Where test.cgi is just a CGI that prints out the string "OK":
>
> #!/bin/sh
> echo "Content-Type: text/plain"
> echo
> echo "OK"
>
> Apache responds with chunked Transfer-Encoding and keeps the connection
> open, clearly HTTP/1.1 behaviors:
>
> HTTP/1.1 200 OK
> Date: Thu, 06 Mar 2003 03:33:42 GMT
> Server: Apache/1.3.27 (Unix)
> Transfer-Encoding: chunked
> Content-Type: text/plain
>
> 3
> OK
>
> 0
I went through the same test this a.m. for a customer with some device
that couldn't handle chunked response. For me, using BrowserMatch to
set downgrade-1.0 eliminated the use of chunking in the response.
$ ~/apache13inst/bin/httpd -V
Server version: Apache/1.3.28-dev (Unix)
Server built: Feb 12 2003 15:26:22
Server's Module Magic Number: 19990320:14
Server compiled with....
browsermatch "GOBBLE" downgrade-1.0
Here are two telnet sessions, one with GOBBLE for the user agent and one
without:
$ telnet 127.0.0.1 10000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /cgi-bin/printenv HTTP/1.1
Host: local
HTTP/1.1 200 OK
Date: Thu, 06 Mar 2003 14:12:30 GMT
Server: Apache/1.3.28-dev (Unix)
Content-language: en, en
Transfer-Encoding: chunked
Content-Type: text/plain
2d9
DOCUMENT_ROOT="/home/trawick/apache13inst/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_HOST="local"
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/trawick/bin:/usr/local/bin:/home/trawick/newbin:/usr/lpp/cmvc/bin"
QUERY_STRING=""
REMOTE_ADDR="127.0.0.1"
REMOTE_PORT="13587"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/home/trawick/apache13inst/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="127.0.0.1"
SERVER_ADMIN="trawick@cs390-1.raleigh.ibm.com"
SERVER_NAME="cs390-1.raleigh.ibm.com"
SERVER_PORT="10000"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE="<ADDRESS>Apache/1.3.28-dev Server at
cs390-1.raleigh.ibm.com Port 10000</ADDRESS>\n"
SERVER_SOFTWARE="Apache/1.3.28-dev (Unix)"
0
^]
telnet> quit
Connection closed.
$ telnet 127.0.0.1 10000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET /cgi-bin/printenv HTTP/1.1
User-agent: GOBBLE
Host: local
HTTP/1.1 200 OK
Date: Thu, 06 Mar 2003 14:12:51 GMT
Server: Apache/1.3.28-dev (Unix)
Content-language: en, en
Connection: close
Content-Type: text/plain
DOCUMENT_ROOT="/home/trawick/apache13inst/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_HOST="local"
HTTP_USER_AGENT="GOBBLE"
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/trawick/bin:/usr/local/bin:/home/trawick/newbin:/usr/lpp/cmvc/bin"
QUERY_STRING=""
REMOTE_ADDR="127.0.0.1"
REMOTE_PORT="13588"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/home/trawick/apache13inst/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="127.0.0.1"
SERVER_ADMIN="trawick@cs390-1.raleigh.ibm.com"
SERVER_NAME="cs390-1.raleigh.ibm.com"
SERVER_PORT="10000"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE="<ADDRESS>Apache/1.3.28-dev Server at
cs390-1.raleigh.ibm.com Port 10000</ADDRESS>\n"
SERVER_SOFTWARE="Apache/1.3.28-dev (Unix)"
downgrade_1_0="1"
Connection closed by foreign host.
$