Duncan, Brian M.
2004-12-20 19:02:12 UTC
I sent this around 10 months ago to the help list. (NO REPLIES) Will
try one more time on this list, since it says it is PROXY related. And
this looks like a bug. (If I am wrong here, please let me know)
MS now admits to this "bug" but tells us they won't fix this till SP2
for MS Sharepoint server. (They told us it would be fixed in SP1, but
that never happened) And since this seems to make Apache malfunction to
the point a buffer overflow could occurr I figured I would try again.
MS's article ID on this is:
Article ID : 840931
I am hoping that someone can tell me how to get Apache's
proxy module (if this is where this exists) to IGNORE the fact when a
redirect is given (301 or 302) without a "Reason Phrase". (Not RFC
complient)
Right now Apache (In Reverse proxy mode) freaks out,
and a buffer overflow could probably be done. (Not much of a security
risk it looks like though)
Thanks! - The original message is below:
-----Original Message-----
From: Duncan, Brian M.
Sent: Thursday, February 05, 2004 10:40 PM
To: 'users-***@httpd.apache.org'
Subject: 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.
***@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.
===========================================================
try one more time on this list, since it says it is PROXY related. And
this looks like a bug. (If I am wrong here, please let me know)
MS now admits to this "bug" but tells us they won't fix this till SP2
for MS Sharepoint server. (They told us it would be fixed in SP1, but
that never happened) And since this seems to make Apache malfunction to
the point a buffer overflow could occurr I figured I would try again.
MS's article ID on this is:
Article ID : 840931
I am hoping that someone can tell me how to get Apache's
proxy module (if this is where this exists) to IGNORE the fact when a
redirect is given (301 or 302) without a "Reason Phrase". (Not RFC
complient)
Right now Apache (In Reverse proxy mode) freaks out,
and a buffer overflow could probably be done. (Not much of a security
risk it looks like though)
Thanks! - The original message is below:
-----Original Message-----
From: Duncan, Brian M.
Sent: Thursday, February 05, 2004 10:40 PM
To: 'users-***@httpd.apache.org'
Subject: 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.
***@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.
===========================================================