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

• Status: RESOLVED
• Resolution: INVALID
• Component: Forms

[Alexander Kellett]

The issue is described in more detail at the URL http://jira.atlassian.com/browse/JRA-13791.

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

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

[Alexey Proskuryakov]

This is an issue in closed source system frameworks. Closing as INVALID to indicate this; the problem will continue to be tracked in Radar.

[Mark Rowe (bdash)]

*** Bug 16158 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

*** Bug 16166 has been marked as a duplicate of this bug. ***

[Dave Minnigeorde]

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.

[David Kilzer (:ddkilzer)]

There is a work-around documented in the Jira bug:

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

[Alexey Proskuryakov]

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

[Dave Minnigeorde]

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

[Amiri Barksdale]

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

[Dave Minnigeorde]

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.

[Amiri Barksdale]

(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

[David Kilzer (:ddkilzer)]

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

[Guillaume Boudreau]

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

[Guillaume Boudreau]

Created attachment 23144 [details]
HTTP trace of invalid Content-Type in GET following a redirect in Google Chrome

[Guillaume Boudreau]

Created attachment 23145 [details]
HTTP trace of the same session in IE7 with no invalid headers

[Alexey Proskuryakov]

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.

[Guillaume Boudreau]

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.

[Alexey Proskuryakov]

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.