Hello.
I'm currently working on a project to migrate some websites from
Apache 1.3.33 to Apache 2.2.20.
For the most part the migration is going smoothly. However we have 1
application which is failing when running transactions against the
updated Apache 2.2.20 instance.
This particular application is expecting the http response to be
chunked (Transfer-Encoding). The application is an embedded http
client used in manufacturing devices and cannot be modified:(
According to someone who has viewed the source on my behalf they say
it's coded to look in the response for "CR LF CR LF followed by the
length in hex". In the packet capture between the client and apache
1.3.33 instance I do in fact see the following.
"Transfer-Encoding: chunked\r\n
Content-Type: text/plain\r\n
\r\n"
When the application hit's the Apache 2.2.20 instance the request is
sent back with the Content-Length header.
While i'm sure the http client is not behaving properly I would like
to solicit some ideas on what I can change on the server to force the
response to be set to "Transfer-Encoding: chunked".
I saw some suggestions about unsetting the content-length header in
Apache but that didn't force a chunked response (nor did it unset the
content-length header).
In the virtualhost section i added
Header unset Content-Length
But the responses still contain that header.
I then tried modifying the php file used to generate the response and added
"header("Transfer-encoding: chunked");
flush();"
But using curl I get the following parse error
<
* Received problem 2 in the chunky parser
Which makes me think the response didn't actually get chunked.
Any ideas on how I can support this certainly misbehaving http
client is appreciated. My Plan B is to leave the 1.3.33 Apache
instance in place but that doesn't feel right.
TIA. Deet.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|