You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Mark Herman II <tu...@cajun.net> on 1997/07/16 21:50:02 UTC

protocol/875: force-response-1.0 bug

>Number:         875
>Category:       protocol
>Synopsis:       force-response-1.0 bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache (Apache HTTP Project)
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Jul 16 12:50:01 1997
>Originator:     turbodog@cajun.net
>Organization:
apache
>Release:        1.2.X
>Environment:
BSDI 3.0.  I believe it will occur on any OS.  I also experience it on Linux.
>Description:
I run the JCount Java access counter at http://www.jcount.com/.  We included
the BrowserMatch lines that were suggested in the FAQ.  This counter works
properly on all browsers I've tried except Internet Explorer 4.0 Preview Release
2.  The BrowserMatch lines tell the server to send back HTTP/1.0 response
headers to IE 4.0 PR 2.  While searching for the cause of this error, I tried
telnetting directly into the server and typing the http requests myself.  I've
found that using the force-response-1.0 directive sends back the HTTP/1.0 header, but
HTTP/1.1 encoded information.  The specific problem that this is causing me is
that if I call my CGI scripts in IE 4.0 PR 2, it has an extra number before the
beginning of my program's output.  It would seem that any Java applet that uses
CGI to communicate with a server runs a chance of running into this problem on
this browser.  I think I will find a simple fix in my particular case, but I
still think this should be addressed.
>How-To-Repeat:
telnet into www.jcount.com port 80, and type the following:
GET /cgi-bin/counter2.cgi?secondary_exposure=true&increment=false&counter_id=30 HTTP/1.1
Host: www.jcount.com

I have set the force-response-1.0 environment variable to help find the problem.
I will be setting this back to normal soon, but for now, the output will be:

HTTP/1.0 200 OK
Then what appears to be a HTTP/1.1 header will follow.  After that, there will be
a blank line, then some hexadecimal number, which is the cause of my problems.
In my case, my program parses the output based on which line it is on.
I am assuming that this new number has something to do with the HTTP/1.1 response,
because it doesn't show up if I request the information using HTTP/1.0.
>Fix:
Instead of having the force-response-1.0 directive just change the first line
of the header sent back, send back a true HTTP/1.0 response
>Audit-Trail:
>Unformatted: