Closed Bug 87743 Opened 23 years ago Closed 23 years ago

darkbasic.com - JPG image attachment displays garbage instead of image.

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 87754

People

(Reporter: sswift, Assigned: bc)

References

()

Details

(Whiteboard: [SYNTAX-HTTP])

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607 BuildID: 2001060703 If you go to this page and click the JPG attachment in the message, you get garbage. I've noticed this problem in Netscape too, but it works in IE. The problem appaears to be that the file extension is upper case instead of lower case. Lower case filenames work fine on this messageboard in both Netscape and Mozilla. Reproducible: Always Steps to Reproduce: 1.Go to page 2.Click JPG attachment 3 [details] [diff] [review]. Actual Results: Get a page of garbage instead of an image. Expected Results: Get an image.
Confirming. Changing the extension to .jpg lowercase on the same page makes image load fine! Making mozilla convert all files to lowercase should not be safe because on some OS (namely unix-alike) should see this as different files
Who said anything about converting the filename? I just want it to load and display the image. Any file with a .JPG extension no matter the case should be seen as a JPEG file.
What i meant: mozilla handles file types internally, and recognizes ".jpg" as images, but not ".JPG", so if mozilla would convert the file to lowercase then it would see it, but this implementation would have lots of problems It is really rare to see a jpg file in lowercase with an uppercase extension. I dont think a commercial webpage would do that, but i guess that file types on mozilla can be changed to include the uppercase files
nc4 reports File MIME Type: text/plain which means it's a server misconfiguration.
Assignee: asa → bclary
Component: Browser-General → Evangelism
QA Contact: doronr → zach
It's ok for me that this bug goes to evangelism But the unkown Filetype decoder fails. If this works with .jpg but not with .JPG we should possible fix this.
Saved the image as test.JPG and uploaded it to one of my webpages http://espectro.hypermart.net/test.JPG works fine I propose marking this one as INVALID Saving the image in the testcase url provided by reporter shows download.php instead of the file name. I think this was reported already but i will report it for now
confirming per previous remarks and setting priority.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [SYNTAX-HTTP]
I'm confused. Is the bug slated to be fixed, or has it been determined not to be a bug? And what's this "evangelism" component... Is that another way of saying that it's a battle between operating systems? :)
> Is the bug slated to be fixed, yes and no. The evangelism component has a definition of fixed which differs from the rest of browser. Fixed means that we convince the site to correct its code so their problem goes away. > or has it been determined not to be a bug? Not a mozilla bug, but worth at least an email to someone. > And what's this "evangelism" component... um, there are good web pages that can answer your question, unfortanately I couldn't really find them. My process was pretty simple, i checked to see if we behaved correctly (we did), and whether the other side behaved foolishly (it did) and concluded that it wasn't a problem w/ the mozilla browser. [Which leads us to a silly conclusion that the Evangelism component doesn't belong in the browser product. If that led to some confusion, I'm sorry.] The problem is that some part of the web server is broken. Usually we don't bother speculating in bug reports because it doesn't help, but since I need to explain my actions, here goes: the web server is apache, which somehow runs php which somehow interprets a php script. When we take a browser (telnet, wget, mozilla, netscape4) and ask the webserver for http://www.darkbasic.com/forum/download.php?f=8&file=screen.JPG it says it's going to send us an object of type text/plain. So one of those 3 elements is responsible for telling us that. We honor its assertion, which is correct per w3 spec. if instead we ask the same server/application for http://www.darkbasic.com/forum/download.php?f=8&file=screen.jpg it reports the object is image/jpeg which we also honor (showing you a picture). Since I can't see the source, i don't know if the php script is doing the mime type lookup, or if php does it, or if apache does it. But it doesn't matter much, because the job of the evangelism component (and the current bug owner) is to contact the site and explain that their code/application(s) are broken. http://sites.netscape.net/ekrockhome/standards.html http://devedge.netscape.com/evangelism > Is that another way of saying that it's a battle between operating systems? No :) Oh, just a reminder: Bugs in this component should not be marked invalid. I hope these comments are more helpful than they are confusing.
Okay, so basically the bug's not gonna get fixed because you guys would rather follow a web standard which allows the webpage to define what's in a file instead of paying attention to the file extension which is a different standard which has been around a lot longer for defining what is in the file? The sad fact is that most webmasters could care less if their website works in Mozilla. So if something works in IE, it should work in Mozilla too, otherwise there's gonna be a lot of pages which never work right in Mozilla because the webmaster only checked them in IE. I stopped using Netscape because it crashed 20 times a day. (That is no exaggeration) IE was much more stable, but didn't allow me to open pages in new windows maximized cpies the current webpage to the new window when I opened it, and did a lot of other irritating things. So I switched to Mozilla. I don't want to have to switch to yet another browser in because the guys developing Mozilla hold the web standard as being more important than functionality for the end user. I hope you also fix the composer tool too... what's with having no ability to specify the size of text in point size? For example, add a feature that lets me specify whether JAVA is on or off for each specific webpage. Even if it breaks the java standard.
Ok, i'm not happy, I had a very long comment and the power failed. > the bug's not gonna get fixed No, i expect it to be fixed, per the definition given above. > follow a web standard yes. > which allows the webpage to define what's in a file Actually the web server, which is very logical. > instead of paying attention to the file extension which is meaningless > which is a different standard There is no such standard. Apple defines/manages a standard for file types. 4 chars for type and for chars for creator. There is no "Standard" for 3 letters. There are less than 18000 such 3 letter combinations, and lots of collisions. A quick list, because the last time i listed them my computer lost power. rpm Real Player or RedHat Package? diff Diff output or QuickTime Digital Video cnf Configuration of microsoft conference doc document, sure, but wordperfect, lotus, microsoft word, wordpad, ...? log Logo Progrmaming language (this was a binary format) or Text Log File bas QuickBasic, QBasic, Visual Basic, PowerBasic. These are only occasionaly compatible bmp Sure bitmap, but microsoft bitmap or something else? rle run length encoding, sure, but encoding _what_? dsp digital signal processor? nope enc encoded or encrypted? nope network monitor something fon phone book? nah font. ins installer file? not today, it's an internet communications settings js JavaScript for a webpage or JScript executable in a console bin binary. binary what? rmi remote method invocation? probably not. usually it's a MIDI file. rle run length encoding. sure, but encoding _what_? plg ? it's a microsoft html file? really, odd. > which has been around a lot longer for defining what is in the file? http://src.doc.ic.ac.uk/computing/internet/rfc/rfc821.txt August 1982 http://src.doc.ic.ac.uk/computing/internet/rfc/rfc822.txt August 13, 1982 http://inventors.about.com/library/weekly/aa033099.htm August 12, 1981 new operating system from Microsoft called MS-DOS 1.0. ok, you got me, dos is 1 year and 1 day older than the mime rfc. Would you believe that extensions weren't really used in anything resembling a standard form until long after 1982? Most people grouped files in directories and then used 11 characters to give their files longer names > webmasters could care less if their website works in Mozilla. we're trying to change that. But i'd argue you're wrong. Query Evangelism component for fixed/wontfix bugs: http://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED &bug_status=CLOSED&resolution=FIXED&resolution=WONTFIX&component=Evangelism 121 Fixed out of 136 bugs. 89%. This is probably better than most other browser components. > So if something works in IE, it should work in Mozilla too, doens't follow > there's gonna be a lot of pages which never work right in Mozilla pages that rely on visualbasicscript or activex controls will probably never work right in mozilla, that's ok they don't work in IE for MacOS or Unix. > because the webmaster only checked them in IE. Most webmasters are responsive and willing to fix their pages. <I don't care what browser you use, don't use, like, or don't like> > guys developing Mozilla hold the web standard as being more important wow. I can't imagine why anyone would believe web standards should be important. > than functionality for the end user. wow. > I hope you also fix the composer tool too... That has nothing to do with this bug report. please refrain from including unrelated comments in bug reports. > no ability to specify the size of text in point size? I dunno. There might be a UI/Style argument against doing it. Search bugzilla, it could just be a bug. > specify whether JAVA is on or off for each specific webpage. that's coming. hopefully by mozilla 1.2 > Even if it breaks the java standard. The java standard specifies the java language and the byte code behavior, it doesn't care about web pages.
This is silly... most of the formats you've listed should be opened with an external program defined by the operating system. "Would you believe that extensions weren't really used in anything resembling a standard form until long after 1982? Most people grouped files in directories and then used 11 characters to give their files longer names" That's fine, and I undertsand your point... there's tons of diffrent file formats with the same extension. But you're being silly. A web broswer does not need to support 5000 diffrent formats. It needs to support a few formats, ask the OS what to do with the ones it doesn't recognize, and when all else fails, if it was something the user clicked on, ask them if they want to save it. Gif's, Jpegs, Png's, Html files, and Text files... Those are most of the basics that the web broswer needs to be able to read. Anything like .JS, .MOV, .RPM or whatever else not reginized should tell the web broswer to look to the OS for the answer of what app can view it, or to the browser plugins. And you're right, the web broswer shouldn't have to look at the file extension. File extensions are stupid. A truly robust app would look at the file's CONTENTS to intelligently determine what the file format is. I have an image viewer for example called COMPUPIC. Wonderful program. It looks at all the files in a directory and determines which format each one is in by it's contents, and if a GIF is mislabeled as a JPG it will notice that and ask me to rename it and will still display it properly even if not renamed. A web broswer should do the same for any files it downloads. It should look at the data it's loading and determine if it's an image or a text file or just garbage binary data and display it appropriately. Sure, it might make a mistake once in a while, but it's gonna make mistakes either way. I'd rather it makes a mistake for one file in a million than for every JPG which someone decided to write the extension in uppercase or where the web server is misconfigured which will happen 100,000 times more often. "> webmasters could care less if their website works in Mozilla. we're trying to change that. But i'd argue you're wrong." How can I be wrong? There's far far less users of Mozilla than IE, (unfortunately) and there's millions of people who don't know what they're doing making websites. Even if they wanted to support Mozilla, they'd have to A, know it exists, and B, know the technical details of what it is they're doing wrong. I'm not computer illiterate, and I didn't know what was causing this behavior in Mozilla. And if I wasn't using Mozilla, I wouldn't have downloaded it to test my websites with, and I wouldn't care if it worked or not because it's used by such a small segment of the web population. Same reason game developers don't write their games to work with Linux or Macs. Not enough of a user base to buy the game to make it a market worth going after. "Most webmasters are responsive and willing to fix their pages." You mean most professional webmasters working for large companies, and not the billions of websites out there run by individuals which I might want to also visit, right? "I can't imagine why anyone would believe web standards should be important." They are important... to a point. If something is put into the standard though that is irritating for the end user, then I say boycott that feature by not supporting it in your web broswer. If they made it a part of the standard such that you could specify in your html code a time limit which the user would have to wait before they could close the window your website is open in, would you support that in Mozilla, even though it would be really irritating to the end user, just to be compliant with the "standard"? Or if part of the standard was that a unique ID code had to be transmitted to the website by the user's PC whenever they visted a webpage, would you implement that? Or would you hack around it so that it returned a fake code if the user so chose so that you could keep the user's broswing habits more private? One thing I wish web broswers would drop is Java. Java is the worst thing ever to happen to the web. Only a few Java apps I've ever used have been useful, and those were ones which displayed sample algorithms running in a window on the page, or ones to compute numbers. But those things just aren't worth it. CGI scripts can do those same things.. they just require a page reload. There's another example of a standard that should be ignored, but unfortunately, you can't really ignore that one now or many pages wouldn't work in Mozilla at all. Anyhow, maybe you can explain to me why it's a good thing for the website to specify what the content of a file is rather than the file itself specifying in some way what content it has?
Summary: JPG image attachment displays garbage instead of image. → darkbasic.com - JPG image attachment displays garbage instead of image.
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Duping to bug 87754 -- another bug on bad server setup on the same site. *** This bug has been marked as a duplicate of 87754 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.