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)
Tracking
(Not tracked)
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.
Comment 1•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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
Assignee | ||
Comment 7•23 years ago
|
||
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.
Reporter | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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.
Reporter | ||
Comment 12•23 years ago
|
||
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?
Assignee | ||
Updated•23 years ago
|
Summary: JPG image attachment displays garbage instead of image. → darkbasic.com - JPG image attachment displays garbage instead of image.
Assignee | ||
Comment 13•23 years ago
|
||
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
Comment 14•23 years ago
|
||
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
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•