Closed
Bug 344111
Opened 18 years ago
Closed 9 years ago
the content-disposition reponse header not taken into acount after submitting an xform
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jan-wijbrand.kolman, Unassigned)
References
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060608 Ubuntu/dapper-security Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060608 Ubuntu/dapper-security Firefox/1.5.0.4
A content-disposition repsonse header like:
Content-Disposition: attachment; filename=bla.foo
will trigger a open file dialog for downloading and saving the requested data. The "filename=bla.foo" part in the header will be used as a default for the name of the file-to-be-saved.
This does not seem to work when submitting an xform though.
If the browser recognizes the content type of the response, the content is shown inline.
If the browser does not recognize the content type, it will show the open file dialog and the last segment of the URL that was used to submit the form to is presented as a default name.
Reproducible: Always
Actual Results:
Content is displayed inline for recognized content types. Open file dialog is shown for unrecognized content types, but without the suggested filename as default.
Expected Results:
I expected to see a open file dialog with the suggested filename as default.
(see attached cgi scripts)
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Reporter | ||
Comment 3•18 years ago
|
||
changed summary to better reflect the problem.
Summary: the filename part in a content-disposition reponse header not taken into acount after submitting an xform → the content-disposition reponse header not taken into acount after submitting an xform
Comment 4•9 years ago
|
||
RIP xforms
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•