[Webkit-unassigned] [Bug 16082] REGRESSION: Issues with JIRA when using Safari 3 (invalid Content-Type header added for HTTP GET redirects)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 8 10:29:14 PST 2008


http://bugs.webkit.org/show_bug.cgi?id=16082





------- Comment #13 from ddkilzer at webkit.org  2008-01-08 10:29 PDT -------
(In reply to comment #12)
> (In reply to comment #11)
> > Jira 3.12 has a work around in it.  We're just doing a jira deploy so was able
> > to switch to 3.12.  
> > 
> > Also see the links to the jira bug for a server side filter patch.
> 
> Actually, I raninto this bug while building a mod_perl web app. I don't think
> those java patches will help me.

You *may be able to use the same logic on the server side to work around the
issue the same way.  (It's been a while since I did any mod_perl, so the
mod_perl engine may use different logic than a Java servlet engine does.)

Without going into the details of how Java servlet filters work, the code
basically wraps an HTTP request such that if the user agent matches Safari 3,
and the request method is "GET", and the Content-Type is set to
"multipart/form-data" (they used "startsWith() in Java), then always return
"null" if some other Java code (e.g., the servlet engine itself) wants to know
what the Content-Type for the request was.

I think mod_perl has the ability to chain/wrap "handlers", so you should write
a small handler that looks for the above conditions, then either "wipes" the
Content-Type field in the request object, or wraps the request object with an
object that says the Content-Type field was never set (but just for this
request).

If that doesn't work, you'll have to dig into the guts of mod_perl (or whatever
is handling the request) to determine a work-around specific to mod_perl.

On the other hand, after reading Comment #10, this may be a different issue. 
Perhaps it would be best if you opened a new bug and included the HTTP headers
from both Safari and the mod_perl server for the whole request.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list