MIME type override for attachments lost in HTTP redirect

RESOLVED FIXED in Bugzilla 3.0

Status

()

Bugzilla
Attachments & Requests
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: WeirdAl, Assigned: Frédéric Buclin)

Tracking

({regression})

3.2.3
Bugzilla 3.0
regression
Bug Flags:
approval +
approval3.4 +
approval3.2 +
approval3.0 +

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Steps to reproduce:
(1) Try to load the URL field in this bug.

Expected results:
User gets a download file dialog.

Actual results:
User sees the attachment in their browser.

Test session with wget:
$ wget http://bugzilla.mozilla.org/attachment.cgi?id=342678&content_type=text/plain
[1] 4996

Alex Vincent@VISTA64 /c/tests
$ --08:10:25--  http://bugzilla.mozilla.org/attachment.cgi?id=342678
           => `attachment.cgi@id=342678'
Resolving bugzilla.mozilla.org... 63.245.209.72
Connecting to bugzilla.mozilla.org|63.245.209.72|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bugzilla.mozilla.org/attachment.cgi?id=342678 [following]

Note the content_type flag has been lost in the HTTP redirect
Assignee: nobody → attach-and-request
Component: Bugzilla: Other b.m.o Issues → Attachments & Requests
OS: Windows Vista → All
Product: mozilla.org → Bugzilla
QA Contact: other-bmo-issues → default-qa
Hardware: x86 → All
Version: other → 3.2.3

Comment 1

9 years ago
I wasn't even aware there was such a redirect...

Comment 2

9 years ago
I mean, I wasn't aware there was such an override.
(Assignee)

Updated

9 years ago
Keywords: testcase → qawanted
Target Milestone: --- → Bugzilla 3.2
(Assignee)

Comment 3

9 years ago
Created attachment 371233 [details] [diff] [review]
patch, v1
Assignee: attach-and-request → LpSolit
Status: NEW → ASSIGNED
Attachment #371233 - Flags: review?(wicked)
(Assignee)

Comment 4

9 years ago
I will take this fix on the 3.0 branch as I regressed this feature there too.
Target Milestone: Bugzilla 3.2 → Bugzilla 3.0
(Assignee)

Updated

9 years ago
Keywords: qawanted
Comment on attachment 371233 [details] [diff] [review]
patch, v1

This does fix the reported case for the content_type parameter for all four branches.

I couldn't find any other parameters that would need to survive through this redirect. Although, this could have been future proofed by using all current query parameters passed and only add new ones when constructing the redirection URL. See sub redirect_to_urlbase in Bugzilla/CGI.pm how this could be done quite easily.
Attachment #371233 - Flags: review?(wicked) → review+
Flags: approval?
Flags: approval3.4?
Flags: approval3.2?
Flags: approval3.0?

Comment 6

9 years ago
Comment on attachment 371233 [details] [diff] [review]
patch, v1

Why not just pass on any extra query string variables?
(Assignee)

Comment 7

9 years ago
(In reply to comment #6)
> Why not just pass on any extra query string variables?

Because I want to avoid any abuse. No other variable is usable/valid when viewing attachments.
(Assignee)

Updated

9 years ago
Flags: approval?
Flags: approval3.4?
Flags: approval3.4+
Flags: approval3.2?
Flags: approval3.2+
Flags: approval3.0?
Flags: approval3.0+
Flags: approval+
(Assignee)

Comment 8

9 years ago
tip:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.156; previous revision: 1.155
done

3.3.4:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.153.2.1; previous revision: 1.153
done

3.2.3:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.144.2.6; previous revision: 1.144.2.5
done

3.0.8:

Checking in attachment.cgi;
/cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v  <--  attachment.cgi
new revision: 1.126.2.4; previous revision: 1.126.2.3
done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
For those who ran into this on bmo, this fix has been deployed to the production servers.
You need to log in before you can comment on or make changes to this bug.