[users@httpd] HTTP Proxy - Configuration to avoid MIME header concatenation

[Paul Fee <pa...@operamail.com>]

Hello all,

Perhaps this is for the Dev list, but I'll ask here first.

I'm using Apache 2.0.54 with mod_proxy to proxy HTTP requests.  I've found no reference to the following issue in goggle or Apache bugzilla.

As Apache reads the data from the Client->Proxy socket, the following call tree is invoked:

process_socket()
ap_process_connection()
ap_run_process_connection()
ap_process_http_connection()
ap_read_request()
ap_get_mime_headers_core()

At the end of ap_get_mime_headers_core() [protocol.c:804], apr_table_compress() is called which identifies multiple headers with the same field name and concatenates them.  e.g.

Original headers:
Accept: image/gif
Accept: image/jpeg

Headers after call to apr_table_compress():
Accept: image/gif, image/jpeg

The RFCs (1945 and 2068) state in section 4.2 that this is acceptable as the interpretation of field value MUST still be the same whether the field is concatenated or not.

However I'm concerned about the following scenario.  Suppose I am responsible for the proxy server but neither the client browser nor the origin server are under my control.

What if an application has been developed between a third party client and server which is sensitive to the format of the headers.  I could easily state that the server MUST treat concatenated headers in the same way as multiple same field-name headers as it is mandated by the RFCs.

However if I only have influence over the proxy, I'm left with the situation where the client/server interaction may work with a direct connection but not through the proxy.  Hence the proxy is considered at fault, even though the non-compliant server is the root cause.

My impression is that Apache calls apr_table_compress() so that subsequent header lookup within apache will not provide ambiguous results - instead the complete (concatenated) field value is available.

However, more transparent proxy behaviour may be required to maintain compatability with a defective origin server.  Would it be possible to make the call to apr_table_compress() optional based on a configuration directive?

Can you see any harmful side-effects to making such a change?

There would be further details to discuss about the implementation, but I'll finish with just a few to keep this message short:

If enabled should it apply proxy requests only?
Should it be configurable with an allow/deny rule set for destination hostnames?
Should the original table of headers remain as the client intended but internal Apache access via apr_table_get() still give a single concatenated value?

Thanks for reading, I look forward to your response.
-- 
Paul Fee

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org