Bug 16082

Summary: REGRESSION: Issues with JIRA when using Safari 3 (invalid Content-Type header added for HTTP GET redirects)
Product: WebKit Reporter: Alexander Kellett <a>
Component: FormsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: amiribarksdale, ap, BlueGus, bougu, dave, ddkilzer, scott
Priority: P1 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://jira.atlassian.com/browse/JRA-13791
Attachments:
Description Flags
HTTP trace of invalid Content-Type in GET following a redirect in Google Chrome
none
HTTP trace of the same session in IE7 with no invalid headers
none
reduced test case (to be served with Apache) none

Description Alexander Kellett 2007-11-21 01:40:04 PST
The issue is described in more detail at the URL http://jira.atlassian.com/browse/JRA-13791.
Comment 1 David Kilzer (:ddkilzer) 2007-11-21 03:19:38 PST
<rdar://problem/5554133>

Looks like this may be closed as INVALID since it works on Tiger, but not on Leopard.  (I know the boundary-generating code is in WebKit, though.)

Comment 2 David Kilzer (:ddkilzer) 2007-11-21 03:21:10 PST
(In reply to comment #1)
> <rdar://problem/5554133>
> 
> Looks like this may be closed as INVALID since it works on Tiger, but not on
> Leopard.  (I know the boundary-generating code is in WebKit, though.)

And by "this" I mean the Bugzilla bug, not the Radar bug.

Comment 3 Alexey Proskuryakov 2007-11-26 03:56:48 PST
This is an issue in closed source system frameworks. Closing as INVALID to indicate this; the problem will continue to be tracked in Radar.
Comment 4 Mark Rowe (bdash) 2007-11-27 18:23:33 PST
*** Bug 16158 has been marked as a duplicate of this bug. ***
Comment 5 David Kilzer (:ddkilzer) 2007-11-28 05:25:07 PST
*** Bug 16166 has been marked as a duplicate of this bug. ***
Comment 6 Dave Minnigeorde 2007-11-29 11:30:01 PST
I just got hit by this doing a demo to the upper mucky-mucks.

AFAICT it IS a web kit issue. (osx: 10.5.1)

The POST uses the multipart as indicated.  A redirect comes back saying go to the /browse/<issue-key>
and then webkit does a GET for that path adding the header of content-type set to multipart.

Sure jira should just ignore things like that but it seems like the content-type shouldn't be set for a GET anyway.  Not my area of expertise by any stretch though.


Comment 7 David Kilzer (:ddkilzer) 2007-11-29 11:49:30 PST
There is a work-around documented in the Jira bug:

http://jira.atlassian.com/browse/JRA-13791

Comment 8 Alexey Proskuryakov 2007-11-29 12:22:34 PST
(In reply to comment #6)
> AFAICT it IS a web kit issue. (osx: 10.5.1)

This is a bug in Apple's closed source frameworks used by WebKit, not in WebKit itself. It is now tracked by Apple internally.
Comment 9 Dave Minnigeorde 2007-11-29 13:30:28 PST
(In reply to comment #8)
> (In reply to comment #6)
> > AFAICT it IS a web kit issue. (osx: 10.5.1)
> 
> This is a bug in Apple's closed source frameworks used by WebKit, not in WebKit
> itself. It is now tracked by Apple internally.
> 

Ah... I see... sorry for my newbiness.

Comment 10 Amiri Barksdale 2008-01-08 09:32:55 PST
Pardon me, but has anyone solved this issue? Safari 3 and Webkit both add their own content-type header to a GET request after a form. In my case Safari added "Content-Type: application/x-www-form-urlencoded" (not "multipart/form-data"), and just ignored my actual content-type header. Here is my redirect:

$r->method('GET');
$r->headers_in->unset('Content-length');
$r->content_type('application/octet-stream');
$r->headers_out->{'Location'} = $url;
$m->abort(302);

Such redirects work in every single other browser except Safari 3 and WebKit. They work fine in Safari 2.

This bug is definitely not closed, it is definitely both WebKit and Safari 3.

Meanwhile, does anyone have any insight into a workaround on the server side?

Amiri
Comment 11 Dave Minnigeorde 2008-01-08 09:44:34 PST
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.
Comment 12 Amiri Barksdale 2008-01-08 09:57:57 PST
(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.

Amiri
Comment 13 David Kilzer (:ddkilzer) 2008-01-08 10:29:14 PST
(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.

Comment 14 Guillaume Boudreau 2008-09-03 13:23:29 PDT
I'm not sure this is not WebKit-related, since Google Chrome has the exact same behavior. (Maybe it's just bad luck and really is a Chrome & Apple bug, but still.)

I'll attach two files with both Chrome and IE7 HTTP trace of a POST on JIRA. In the Chrome one, you can see that the last GET has a weird Content-Type header that shouldn't be there:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryAA0gAAGMAACPAARi

Ref to Chrome bug: http://code.google.com/p/chromium/issues/detail?id=843
Comment 15 Guillaume Boudreau 2008-09-03 13:24:17 PDT
Created attachment 23144 [details]
HTTP trace of invalid Content-Type in GET following a redirect in Google Chrome
Comment 16 Guillaume Boudreau 2008-09-03 13:25:00 PDT
Created attachment 23145 [details]
HTTP trace of the same session in IE7 with no invalid headers
Comment 17 Alexey Proskuryakov 2008-09-04 00:47:31 PDT
This bug was supposed to be fixed in Mac OS X 10.5.3, and in Safari 3.1 on Windows - can you still reproduce it in Safari? I have verified that a reduced test case that I made works correctly, but maybe there is more to it (I do not have access to any unpatched Jira installation).

It's indeed strange that Google Chrome has the same issue.
Comment 18 Guillaume Boudreau 2008-09-04 06:21:41 PDT
Indeed, it seems fixed in Safari; tested an unpatched JIRA 3.7 with Safari 3.1.2 on Windows, and with whatever Safari is included in Mac OS X 10.5.4, and both worked fine.
Comment 19 Alexey Proskuryakov 2008-09-04 06:34:10 PDT
Created attachment 23168 [details]
reduced test case (to be served with Apache)

Here is the test case I've been talking about. It should be served with Apache to work.