This is a multi-part message in MIME format.
------_=_NextPart_001_01C4E6C6.69A54431
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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)=0D
=0D
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.=0D
=0D
MS's article ID on this is:=0D
Article ID : 840931=0D
=0D
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)=0D
=0D
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)
=0D
=0D
Thanks! - The original message is below:
=0D
=0D
-----Original Message-----
From: Duncan, Brian M.=0D
Sent: Thursday, February 05, 2004 10:40 PM
To: 'users-help [at] httpd.apache.org'
Subject: Reverse Proxy and MS Sharepoint
question. (Apache possibly mishandling poorly formatted Satus-Line
header)
=0D
=0D
Question, I know this is long, sorry..
=0D
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.
=0D
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..
=0D
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)
=0D
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.
=0D
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.
=0D
A valid 301 looks something like this according
to RFC 1945:
=0D
Status-Line =3D HTTP-Version SP Status-Code SP
Reason-Phrase CRLF
=0D
Status-Code in this case is a 301.
=0D
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. =0D
=0D
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.
=0D
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.
=0D
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?=0D
=0D
Here is the RFC explanation on Satus-Line:
=0D
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.=0D
=0D
=0D
=0D
Status-Line =3D HTTP-Version SP Status-Code
SP Reason-Phrase CRLF
=0D
Thanks for any help on this.
=0D
=0D
brian.duncan [at] kmzr.com
=0D
=0D
=0D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C4E6C6.69A54431
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial><FONT color=
=3D#0000ff><FONT=0D
size=3D2><SPAN class=3D898182018-20122004> I</SPAN> sent this=
around 10=0D
months ago to <SPAN=0D
class=3D611080119-20122004> the help</SPAN><SPAN=0D
class=3D611080119-20122004> </SPAN> list. (NO REPLIES) Will try=
one=0D
more time<SPAN class=3D611080119-20122004> on this list, since=0D
it says it is PROXY related. And this looks like a bug. =
(If I=0D
am wrong here, please let me=0D
know) </SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial><FONT color=
=3D#0000ff><FONT=0D
size=3D2><SPAN=0D
class=3D611080119-20122004></SPAN></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial><FONT size=
=3D2><SPAN=0D
class=3D611080119-20122004> </SPAN>MS now admits to this "bug" but=
tells us=0D
they won't fix this till SP2 for MS Sharepoint server.<SPAN=0D
class=3D611080119-20122004><FONT color=3D#0000ff> (They told us it=
would be=0D
fixed in SP1, but that never happened) And since this seems to make=
Apache=0D
malfunction to the point a buffer overflow could occurr I figured=
I=0D
would try again. </FONT></SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2>MS's article ID on this is:=0D
<TABLE>
<TBODY>
<TR>
<TD class=3Dlabel>Article ID</TD>
<TD class=3Dtext>:</TD>
<TD class=
=3Dtext>840931</TD></TR></TBODY></TABLE></FONT></SPAN></DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial><FONT=0D
color=3D#0000ff><FONT size=3D2>I am hoping that someone can tell me how=
to get=0D
Apache's proxy module (if this is where this exists) to IGNORE the fact=
when=0D
a redirect is given (301 or 302) without a "Reason Phrase".<SPAN=0D
class=3D611080119-20122004> (Not RFC=0D
complient) </SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2>Right now Apache <SPAN class=
=3D898182018-20122004> (In=0D
Reverse proxy mode) </SPAN>freaks out, and a buffer overflow could=
=0D
probably be done. (Not much of a security risk it looks like=0D
though)</FONT></SPAN></DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2>Thanks! - The original message is below:</FONT></SPAN></DIV>
<DIV><SPAN class=3D147215717-20122004><FONT face=3DArial color=
=3D#0000ff=0D
size=3D2></FONT></SPAN> </DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN class=
=3D147215717-20122004><FONT=0D
face=3DArial color=3D#0000ff></FONT></SPAN></FONT></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=
=3Dleft><FONT=0D
face=3DTahoma><FONT size=3D2><SPAN=0D
class=3D147215717-20122004> </SPAN>-----Original=0D
Message-----<BR><B>From:</B> Duncan, Brian M. <BR><B>Sent:</B>=
Thursday,=0D
February 05, 2004 10:40 PM<BR><B>To:</B>=0D
'users-help [at] httpd.apache.org'<BR><B>Subject:</B> Reverse Proxy and MS=
=0D
Sharepoint question. (Apache possibly mishandling poorly formatted=0D
Satus-Line header)<BR><BR></DIV></FONT></FONT>
<DIV><FONT face=3DArial size=3D2>Question, I know this is long,=
=0D
sorry..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Can anyone point me in the=
right=0D
direction of where to ask this question if this is the wrong mailing=
=0D
list?<SPAN class=3D277403004-06022004> It looked like it from=
what I=0D
read.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We have successfully been using=
Apache 1.3.x=0D
for around 1.5-2 years to reverse proxy various applications. =0D
iNotes, OWA, some custom http applications etc..</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>All have usually required some=
tweaking to=0D
get running behind Apache as <SPAN=0D
class=3D277403004-06022004>the</SPAN> reverse proxy. We have=
finally=0D
run into an application that will not work behind Apache and the=
problem=0D
is looking like it is due to Microsoft and not conforming to an RFC=0D
standard. (That point is arguable by some I have spoken=
with) =0D
I have verified this occurs with Apache 1.3.x and 2.x Apache.=
(Running=0D
under linux if this matters)</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The product we are trying to reverse=
proxy is=0D
Microsoft Share point. I was told it was released in October of 2003,=
=0D
which makes it pretty young. I think it's a 1.0=0D
release.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is the problem, Apache reverse=
proxies=0D
to the Share point just fine, you authenticate through active=
direct<SPAN=0D
class=3D277403004-06022004>ory</SPAN> (in our environment) then the=
share=0D
point server sends a 301 redirect to a page called=
default.aspx. =0D
This is where the trouble starts.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>A valid 301 looks something like=
this=0D
according to RFC 1945:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Status-Line =3D HTTP-Version SP=
Status-Code SP=0D
Reason-Phrase CRLF</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Status-Code in this case is a=0D
301.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The problem is MS share point does=
not pass=0D
ANY reason-Phrase. It just passes a single space after the=0D
Status-Code and a CRLF if I remember correctly. This Apaches'=
proxy=0D
pass completely mis-interprets and adds it's own data in and the web=
=0D
browser on the other side comes up with errors. We have=0D
contacted MS and they won't be willing to fix this issue (at least I=
think=0D
it's an issue at the moment) until their SP 1, they don't think this=
=0D
justifies a hot fix. Their development even stated they are=
adhering=0D
to the RFC with a null string as the=0D
Reason-Phrase. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial><FONT size=3D2>I was told by them a null=
string is=0D
equivalent to a Reason-Phrase, or good enough. I never knew a=
blank=0D
string could be considered a text phrase as the RFC puts it.<SPAN=0D
class=3D277403004-06022004> We have never seen this because=
EVERY=0D
application I have seen that does redirects that we have reverse=
proxied,=0D
has the reason-phrase included.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I was also told by the MS tech that=
looked=0D
into this (very helpful) that it looked like the act of this=0D
happening with share point and debug level on apache turned up that a=
=0D
buffer overflow might be occurring because of this. Don't know=
if=0D
this is true though. He said it was logging major hiccups that=
=0D
looked bad. I have not verified this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>My question is this. After=
looking=0D
through some of the source for Apache 1.3.27 proxy modules I see=
there is=0D
comments in the source code for covering some other unrelated issues=
IIS=0D
has had in the past with improperly formatted headers or=
something. =0D
Can anyone point me in the direction to how I could modify the source=
to=0D
not care about getting status-lines missing reason phrases?=
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here is the RFC explanation on=0D
Satus-Line:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The first line of a Full-Response=
message is=0D
the Status-Line, consisting of the protocol version followed by a=
numeric=0D
status code and its associated textual phrase, with each element=
separated=0D
by SP characters. No CR or LF is allowed except in the final CRLF=0D
sequence. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV><FONT face=
=3DArial size=3D2>
<DIV><FONT color=
=3D#0000ff></FONT><BR> =0D
Status-Line =3D HTTP-Version SP Status-Code SP Reason-Phrase=
CRLF</DIV>
<DIV><FONT color=3D#0000ff></FONT> </DIV>
<DIV>Thanks for any help on this.</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><SPAN=0D
class=3D132281617-23102003><SPAN class=3D056302716-20102003>
<DIV><FONT face=3DArial size=3D1></FONT> </DIV>
<DIV><FONT face=3DArial size=3D1><A=0D
href=
=3D"mailto:brian.duncan [at] kmzr.com">brian.duncan [at] kmzr.com</A></FONT></DIV></S=
PAN></SPAN></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff=0D
size=
=3D2></FONT> </DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTM=
L>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D
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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
</font></td></tr></table>
------_=_NextPart_001_01C4E6C6.69A54431--
