You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "Duncan, Brian M." <br...@kmzr.com> on 2004/02/06 05:44:26 UTC
[users@httpd] Reverse Proxy and MS Sharepoint question. (Apache possibly mishandling poorly formatted Satus-Line header)
Question, I know this is long, sorry..
Can anyone point me in the right direction of where to ask this question
if this is the wrong mailing list? It looked like it from what I read.
We have successfully been using Apache 1.3.x for around 1.5-2 years to
reverse proxy various applications. iNotes, OWA, some custom http
applications etc..
All have usually required some tweaking to get running behind Apache as
the reverse proxy. We have finally run into an application that will
not work behind Apache and the problem is looking like it is due to
Microsoft and not conforming to an RFC standard. (That point is
arguable by some I have spoken with) I have verified this occurs with
Apache 1.3.x and 2.x Apache. (Running under linux if this matters)
The product we are trying to reverse proxy is Microsoft Share point. I
was told it was released in October of 2003, which makes it pretty
young. I think it's a 1.0 release.
This is the problem, Apache reverse proxies to the Share point just
fine, you authenticate through active directory (in our environment)
then the share point server sends a 301 redirect to a page called
default.aspx. This is where the trouble starts.
A valid 301 looks something like this according to RFC 1945:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code in this case is a 301.
The problem is MS share point does not pass ANY reason-Phrase. It just
passes a single space after the Status-Code and a CRLF if I remember
correctly. This Apaches' proxy pass completely mis-interprets and adds
it's own data in and the web browser on the other side comes up with
errors. We have contacted MS and they won't be willing to fix this
issue (at least I think it's an issue at the moment) until their SP 1,
they don't think this justifies a hot fix. Their development even
stated they are adhering to the RFC with a null string as the
Reason-Phrase.
I was told by them a null string is equivalent to a Reason-Phrase, or
good enough. I never knew a blank string could be considered a text
phrase as the RFC puts it. We have never seen this because EVERY
application I have seen that does redirects that we have reverse
proxied, has the reason-phrase included.
I was also told by the MS tech that looked into this (very helpful) that
it looked like the act of this happening with share point and debug
level on apache turned up that a buffer overflow might be occurring
because of this. Don't know if this is true though. He said it was
logging major hiccups that looked bad. I have not verified this.
My question is this. After looking through some of the source for
Apache 1.3.27 proxy modules I see there is comments in the source code
for covering some other unrelated issues IIS has had in the past with
improperly formatted headers or something. Can anyone point me in the
direction to how I could modify the source to not care about getting
status-lines missing reason phrases?
Here is the RFC explanation on Satus-Line:
The first line of a Full-Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP characters.
No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Thanks for any help on this.
brian.duncan@kmzr.com
===========================================================
Important:
This electronic mail message and any attached files contain information
intended for the exclusive use of the individual or entity to whom it is
addressed and may contain information that is proprietary, privileged,
confidential and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any viewing,
copying, disclosure or distribution of this information may be subject to
legal restriction or sanction. Please notify the sender, by electronic
mail or telephone, of any unintended recipients and delete the original
message without making any copies.
===========================================================