If the extension of a webpage document isn't given in the URL, or if the extension in the URL doesn't match one of the recognized extensions for the content, mozilla should add an extension to make the saved file be the correct type to ensure that nothing gets lost. URL DEFAULT FILE TYPE http://foo.bar/ index.html Webpage (*.html, *.htm) http://foo.bar/index.html index.html Webpage (*.html, *.htm) http://foo.bar/index.htm index.htm Webpage (*.html, *.htm) http://foo.bar/cgi/cgi.exe cgi.exe.html Webpage (*.html, *.htm) http://foo.bar/cgi/cgi.cgi cgi.cgi.html Webpage (*.html, *.htm) http://foo.bar/cgi/image.cgi image.cgi.gif GIF Image (*.gif) depending on http://foo.bar/cgi/image.cgi image.cgi.jpg JPG Image (*.jpg) the image For each of those, there would also be an "all files (*.*)" option. I'm not sure how much of this is specific to Win32. This should probably only apply to http and https.
moving to XPapps, should belong there.
Assignee: cbegle → don
Component: Browser-General → XPApps
QA Contact: asadotzler → paulmac
es una dupa, sairuh?
QA Contact: paulmac → sairuh
bug exists for index files not getting name (and extension): bug 24817. bill, d'you remember the bug for cgi file saving? it rings familiar...
Assignee: don → law
Yes, and I speculated that I had such a bug in comments I added to yet another bug like this one. However, I can't find any such bug in my current list. So, I think we should keep this one, especially since it does such a good job of mentioning *all* the problem areas.
One thing I forgot to mention explicitly: if a URL ends in .gif but the server gives sends jpeg image (along with a content-type consistent with jpeg), the file should be saved as *.jpg or as *.gif.jpg, because most (Win32?) programs won't figure out that the extension is wrong when trying to read the file later. I've never actually seen a site put bogus extensions in its URLs, but I wouldn't be surprised to see a site try to prevent its users from saving images this way.
I disagree with this idea. I remember back in IE 3.x somewhere where it was impossible to save some files because the browser insisted that it wanted to add an extension of its own choosing. If this goes in, it should be a preference. Jason
Well, I'm sure this would be done in mozilla in a way that wouldn't prevent you from removing the added extension.
Component: XP Apps → XP Apps: GUI Features
according to bug 22861, it is possible for cgi scripts to suggest a filename.
wrt Jason Heard, I presume that this is only a suggested file name/type, and since the user can select some other type and some other name.... I also expect we support save as "this.arbitrary", where the quotes force the dropdown specified extension to be ignored, so the file gets the exact name typed w/in the quotes.
OS: Windows 98 → All
Hardware: PC → All
Related: bug 67901, "When saving files, file widget should be initialized with page title" (instead of with filename on server).
See also bug 87888, file extension in content-disposition header not used in file-picker filter
->giving to mscott for the nonce, while bill is away...
Assignee: law → mscott
Status: ASSIGNED → NEW
I agree that it should automagically detect what type of file it's dealing with and providing the default extension. This would be best when dealing with ASPs or CGIs that give you images but don't really include the extension anywhere in the url. Maybe you could get what type of image it is from ImgLib and give that as the default. Maybe even do the same thing with text, like if a page has no HTML tags in there or no shell commands or something suggest saving as .txt
on windows the mime type registry goes from mimetype to default extension, we should use that for matching.
spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)
Component: XP Apps: GUI Features → File Handling
*** Bug 106867 has been marked as a duplicate of this bug. ***
This is now fixed, modulo bug 57113. The fix landed as part of the "save complete page" changes.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
rs vrfy --related / newer bugs are filed separately.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.