httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duncan, Brian M." <>
Subject [users@httpd] RE: Reverse Proxy and MS Sharepoint question. (Apache possibly mishandling poorly formatted Satus-Line header) (FOUND SOLUTION)
Date Tue, 21 Dec 2004 14:36:54 GMT


No one had any ideas regarding the problem I described below.  Graham Leggett was nice enough
to point me to the Archives because he said he recalled people discussing this issue before.
 (I did look, could not find anything besides my message from almost a year ago regarding
this issue)

I found a solution, so I thought I would post it just in case someone else comes looking for

Apache 1.3.33 has a fix in it for this exact issue. (It was actually a fix from like 1.3.29
I believe)  So I assume that the issue was also addressed in 2.x, last year I tested this
with 2.x and had the same issue.

Unfortunalty I am unable to verify at this time if 2.x is fixed.  -- I don't know both 2.x
and 1.3.x are both updated when a bug is found in one that might be in the other.

>From the Changelog: (I am assuming this is what fixed it)

  *) When using Redirect in directory context, append requested query
     string if there's no one supplied by configuration. PR 10961.
     [André Malo]

	-----Original Message-----
	From: Duncan, Brian M.
	Sent: Monday, December 20, 2004 12:20 PM
	To: ''
	Subject: RE: Reverse Proxy and MS Sharepoint question. (Apache possibly mishandling poorly
formatted Satus-Line header)

	 I sent this around 10 months ago to this list. (NO REPLIES)  Will try one more time.  MS
now admits to this "bug" but tells us they won't fix this till SP2 for MS Sharepoint server.

		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".
		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: ''
			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.



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.

View raw message