RE: Reverse Proxy and MS Sharepoint question. (Apache possibly mishandling poorly formatted Satus-Li

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@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@kmzr.com
=0D
=0D
=0D



==================== =====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
------_=_NextPart_001_01C4E6C6.69A54431
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=3D#0000ff=0D
size=3D2> 

=3D#0000ff=0D
size=3D2>MS's article ID on this is:=0D

Article ID

:

=3Dtext>840931

=3D#0000ff=0D
size=3D2> 

color=3D#0000ff>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". class=3D611080119-20122004>  (Not RFC=0D
complient) 

=3D#0000ff=0D
size=3D2> 

=3D#0000ff=0D
size=3D2>Right now Apache  =3D898182018-20122004> (In=0D
Reverse proxy mode) freaks out, and a buffer overflow could=
=0D
probably be done.  (Not much of a security risk it looks like=0D
though)

=3D#0000ff=0D
size=3D2> 

=3D#0000ff=0D
size=3D2> 

=3D#0000ff=0D
size=3D2>Thanks! - The original message is below:

=3D#0000ff=0D
size=3D2> 

=3D147215717-20122004> face=3DArial color=3D#0000ff> 

=3Dleft> face=3DTahoma> class=3D147215717-20122004> -----Original=0D
Message-----
From: Duncan, Brian M.
Sent:=
Thursday,=0D
February 05, 2004 10:40 PM
To:=0D
'users-help@httpd.apache.org'
Subject: Reverse Proxy and MS=
=0D
Sharepoint question. (Apache possibly mishandling poorly formatted=0D
Satus-Line header)

Question,  I know this is long,=
=0D
sorry..

 

Can anyone point me in the=
right=0D
direction of where to ask this question if this is the wrong mailing=
=0D
list?  It looked like it from=
what I=0D
read.

 

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..

 

All have usually required some=
tweaking to=0D
get running behind Apache as  class=3D277403004-06022004>the 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)

 

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.

 

This is the problem, Apache reverse=
proxies=0D
to the Share point just fine, you authenticate through active=
direct class=3D277403004-06022004>ory (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.

 

A valid 301 looks something like=
this=0D
according to RFC 1945:

 

Status-Line =3D HTTP-Version SP=
Status-Code SP=0D
Reason-Phrase CRLF

 

Status-Code in this case is a=0D
301.

 

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.  

 

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. 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.

 

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.

 

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?=

 

Here is the RFC explanation on=0D
Satus-Line:

 

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.

 

=3DArial size=3D2>

=3D#0000ff>
      =0D
Status-Line =3D HTTP-Version SP Status-Code SP Reason-Phrase=
CRLF

 

Thanks for any help on this.

class=3D132281617-23102003>

 

href=
=3D"mailto:brian.duncan@kmzr.com">brian.duncan@kmzr.com

PAN>

 

 

size=
=3D2> 

Re: Reverse Proxy and MS Sharepoint question. (Apache possibly mishandlingpoorly formatted Satus-Lin

This is a cryptographically signed message in MIME format.

--------------ms000109040705030202010301
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Duncan, Brian M. wrote:

> 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.

This topic has come up before, the archives should uncover the solution.
I do recall a workaround going in to fix this problem quite a while back.

The best place to get help is on the main Apache user's list - this list
was for development discussions on proxy, which moved back into the
mainstream httpd mailing lists quite a while back. You'll get a far
better response from the users list.

Regards,
Graham
--

--------------ms000109040705030202010301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIJGzCC
AugwggJRoAMCAQICAwyZ8DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJa QTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjMwMTUxNjQ1WhcNMDUw NjMwMTUxNjQ1
WjBdMRAwDgYDVQQEEwdMZWdnZXR0MQ8wDQYDVQQqEwZHcmFoYW0xFzAVBgNV BAMTDkdyYWhh
bSBMZWdnZXR0MR8wHQYJKoZIhvcNAQkBFhBtaW5mcmluQHNoYXJwLmZtMIIB IjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwbwE90xkX5511UvMm4pwnFvv0nIIORsm +b+7Vgf04cob
H+fQaDVSDgKfZBm4lgoKQtv/2N+jXxzKtubau6yNMYvN+7iVkQJuLIjpo4DQ 2tb+hIvVsFvc
WkkFpm2+a8lIop1grh2OVIfxHfI/3OA4LbX1Ryq2qAou7TzQh6Te8KjdSigb f1l2gAyCT4ex
wLosSdHcTzv2WrYePJP107czC9gE237E68b+63Wmrc42Q4toz09XAaJnxebq SXWKhSx4h8cv
10hweAYXF5WiEUbINGoRD3V7pWRTbOBcz/oPpD8kh6kSu7iyDuchdOfIpy15 0ff/FCtI8h7f
LEXnBvh16wIDAQABoy0wKzAbBgNVHREEFDASgRBtaW5mcmluQHNoYXJwLmZt MAwGA1UdEwEB
/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAgTOjVmbVAi4gtKNhUI2UcMWE56z6 nG7KxQZ2EmJS
IDhXopbZsXtuOugBDxI1X49aqyQqOktHgWjiii/G0poKhNei3IrUuPB2bp9z o8MtiyB2brXg
lvj5N90jsA94MEMtnDLcdlP4C+XkyzarbUAh9TJxxmleateHTyZWIOZcPR0w ggLoMIICUaAD
AgECAgMMmfAwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMB4XDTA0MDYzMDE1MTY0NVoXDTA1MDYzMDE1MTY0 NVowXTEQMA4G
A1UEBBMHTGVnZ2V0dDEPMA0GA1UEKhMGR3JhaGFtMRcwFQYDVQQDEw5HcmFo YW0gTGVnZ2V0
dDEfMB0GCSqGSIb3DQEJARYQbWluZnJpbkBzaGFycC5mbTCCASIwDQYJKoZI hvcNAQEBBQAD
ggEPADCCAQoCggEBAMG8BPdMZF+eddVLzJuKcJxb79JyCDkbJvm/u1YH9OHK Gx/n0Gg1Ug4C
n2QZuJYKCkLb/9jfo18cyrbm2rusjTGLzfu4lZECbiyI6aOA0NrW/oSL1bBb 3FpJBaZtvmvJ
SKKdYK4djlSH8R3yP9zgOC219UcqtqgKLu080Iek3vCo3UooG39ZdoAMgk+H scC6LEnR3E87
9lq2HjyT9dO3MwvYBNt+xOvG/ut1pq3ONkOLaM9PVwGiZ8Xm6kl1ioUseIfH L9dIcHgGFxeV
ohFGyDRqEQ91e6VkU2zgXM/6D6Q/JIepEru4sg7nIXTnyKctedH3/xQrSPIe 3yxF5wb4desC
AwEAAaMtMCswGwYDVR0RBBQwEoEQbWluZnJpbkBzaGFycC5mbTAMBgNVHRMB Af8EAjAAMA0G
CSqGSIb3DQEBBAUAA4GBAIEzo1Zm1QIuILSjYVCNlHDFhOes+pxuysUGdhJi UiA4V6KW2bF7
bjroAQ8SNV+PWqskKjpLR4Fo4oovxtKaCoTXotyK1Ljwdm6fc6PDLYsgdm61 4Jb4+TfdI7AP
eDBDLZwy3HZT+Avl5Ms2q21AIfUyccZpXmrXh08mViDmXD0dMIIDPzCCAqig AwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu ZzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1m cmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3 DQEBAQUAA4GN
ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph 8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67 GD4Hv0CAAmTX
p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYB
Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBl
cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYD
VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2as
Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSx mRsAxRoLgnSe
JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4 gtwhGTXeJLHT
HUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMMmfAwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkD MQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMjIwMjA1MTQ1WjAjBgkqhkiG9w0B CQQxFgQUAJIE
bKJ6Wrq9N1j3OnBJhjixmGIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3Vpbmcg
Q0ECAwyZ8DB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMMmfAwDQYJKoZIhvcNAQEBBQAEggEAgmQu MYU1KGc7wlS9
iBEs1eb0hcBbQYvrNeg6iiiSNIuuNVjNbVygD9mmTrJiUnXEncqPcDAe9Oe/ jVJAGXEM+OVG
HyoEKn/JL6CdriOu4OtO2YEn1zVxk+1kRNhXDaMVPDinadNt+Cw+IOa7Zd9V 3aluFuhthlZS
fLFmLtf3YB+ynqf5C4GV81qblZusimkE6zNQg8cXMwqLgGYB7cENFPYIA/ed ErBODtgAlUju
uD2+6HaRoOaNvJL2emlHfNf9bCAWmVOB4dyM/BRYRYmXxhBrTICrRYtsSKUt 0WBFYehFFPYk
U+UzRCT8o3O4FeMnFnhSH+fBnimeS3IS1EPd3QAAAAAAAA==
--------------ms000109040705030202010301--