image/pjpeg vs image/jpeg
Jerry Franz
> snow...@xmission.xmission.com (Snowhare) writes:
>> Tom Lane <t...@netcom.com> wrote:
>>> But it is certainly far from universal, yet. I couldn't in good
>>> conscience recommend that you use p-JPEG today on a page intended for a
>>> wide Web audience. I hope that the situation will change fairly quickly,
>>> and that p-JPEG will be reasonably safe for general use by, say, this
>>> summer.
>
>> I would amend that with 'unless you are willing and able to do content
>> negotiation.' Netscape (at least) sends an Accept header with
>> 'image/pjpeg' that can be used efficiently to negotiate between jpeg and
>> p-jpeg. I am now coverting some of my sites to take advantage of this
>> using Apache's content negotiation features.
>
>Actually, I'd entreat you not to do that, as it will certainly break your
>pages on every other browser.
Depends on how you define 'break'. In this context, for me 'break' means that
a browser gets a media type they cannot display. Detecting on image/pjpeg
insures that this *highly* undesirable event does not happen. The choice
is not between 'right' negotiation and 'wrong' negotiation. It is between
serving progressive jpegs to the two browsers I know provide image/pjpeg
in their request headers (with non-progressive jpeg going to everyone else)
and serving non-progressive jpeg to *everyone*.
>Netscape, with their customary disdain for standards conformance, decided
>to start sending "Accept: image/pjpeg" without bothering to obtain a
>formal registration of that media type code. Nor did they try very hard
>to obtain concurrence of other JPEG-interested developers that a separate
>MIME type was appropriate. (There was substantial discussion of this
>point in the IJG email list last summer. As far as I recall, Netscape's
>representative was in a small minority; the consensus was that a new type
>was not needed.)
The consensus was wrong. (Reasoning below)
>
>Using image/pjpeg without registration is a clear violation of the
>Internet media type standards. AFAIK, Netscape 2.beta is the only
>p-JPEG-capable browser that will send this illegal type code.
I know that at least one other popular browser (Spyglass Mosaic) also
sends a image/pjpeg accepts header. I am not aware of any other
popular browser that *can* render p-jpeg as they download (Arena doesn't
make it on *either* qualification - it is not popular and it does
not render images as they arrive).
>
>Suppressing p-JPEG availability to browsers that play by the rules is not
>the way to go. You should not configure your server to do that.
The IJG list had better get cracking on registering image/pjpeg then. Because
image/pjpeg is here. Care to make a bet regarding its market acceptance during
the next six months? (I'm serious about this - I am perfectly willing
to put my money where my mouth is: I will bet that *regardless* of
whether or not image/pjpeg is formally registered that more than 90%
of browser makers that implement p-jpeg in the next six months will send
image/pjpeg in their accept headers. Decision to be made on 1996-8-8).
Bluntly - the IJG list was *wrong* not to register a new subtype for p-jpeg.
Since p-jpeg is *not* interoperable with older non-p-jpeg implementations it
*is* a new media subtype.
It is *NOT* acceptable to serve p-JPEG blindly and pray that the browser
at the other end will somehow be able display it. If that was my only
choice - I just wouldn't use p-JPEG at all. I am sure that the many
other web authors who make their *living* doing this feel the same.
Negotiating on image/pjpeg *at worst* gives a browser that could
display p-jpeg a non-progressive jpeg and does not break *even one*
browser in current existence by sending something it can not understand.
Benjamin Franz
Tom Lane
>>> Netscape (at least) sends an Accept header with
>>> 'image/pjpeg' that can be used efficiently to negotiate between jpeg and
>>> p-jpeg. I am now coverting some of my sites to take advantage of this
>>> using Apache's content negotiation features.
>>
>> Actually, I'd entreat you not to do that, as it will certainly break your
>> pages on every other browser.
> Depends on how you define 'break'. In this context, for me 'break' means that
> a browser gets a media type they cannot display. Detecting on image/pjpeg
> insures that this *highly* undesirable event does not happen. The choice
> is not between 'right' negotiation and 'wrong' negotiation. It is between
> serving progressive jpegs to the two browsers I know provide image/pjpeg
> in their request headers (with non-progressive jpeg going to everyone else)
> and serving non-progressive jpeg to *everyone*.
That means that you fail to serve progressive JPEG to most of the
p-JPEG-capable browsers out there. If you are dead set on having your
pages show non-broken images to every browser without any user interaction,
fine; that's a legitimate goal. But I suggest you forget JPEG entirely and
use GIF. Much safer. As shown below, if you rely on Accept: headers then
you will not be sending *anything* to some large fraction of browsers.
>> Using image/pjpeg without registration is a clear violation of the
>> Internet media type standards. AFAIK, Netscape 2.beta is the only
>> p-JPEG-capable browser that will send this illegal type code.
> I know that at least one other popular browser (Spyglass Mosaic) also
> sends a image/pjpeg accepts header. I am not aware of any other
> popular browser that *can* render p-jpeg as they download
You clearly haven't a clue about the state of p-JPEG support. Check
the JPEG FAQ for the names of some other p-JPEG-capable browsers.
(The FAQ doubtless doesn't list 'em all, either.)
The only non-Netscape p-JPEG-capable browser that I have installed at
this moment is Microsoft Internet Explorer (Mac 2.0b2). It does not
send Accept image/pjpeg; indeed its accept header doesn't mention any
image/* types at all. (I just verified this with a CGI test page.)
Since MSIE is a Spyglass derivative, this strongly suggests that other
flavors of Spyglass Mosaic don't send Accept image/pjpeg either.
Exactly what version of Spyglass are you referring to above?
Have you *checked* what it sends?
I believe that Netscape 2.0x is the only major browser that sends
image/pjpeg, but I have no direct way of proving this. (Anybody
know of a browser test site that keeps track of Accept: headers?)
Now, you may be one of those folks who think that whatever Netscape
does is The Standard and everyone else should just fall into line.
I respectfully disagree.
> The IJG list had better get cracking on registering image/pjpeg then.
If you think it's necessary, perhaps *you* should get cracking on it.
We made our decision, and I remain convinced it was the right one.
This issue was discussed to death last summer, and the consensus was
that it was a band-aid to fix a short-term problem. If content type
negotiation were workable and widely used, there would have been more
of a motivation to set up image/pjpeg as a distinct type. But the fact
is that content type negotiation *doesn't* work. Far too few browsers
send useful Accept: lists; most rely on Accept: */*. (Netscape is one
of the big offenders, btw. It is amusing to note that there is *no*
overlap between the Accept: lists of Netscape and Internet Explorer
except for */*. Netscape calls out four or so image/xxx types, and
leaves all else to */*; IE calls out four or five audio/xxx types,
and leaves the rest to */*. There's no way that you can intelligently
serve the right file type to both these major browsers if you rely only
on their Accept: headers.)
In fact, if you were to try to get browser vendors to send useful
Accept: lists, you'd probably be laughed at. I have heard Netscape
engineers say in so many words that they deliberately keep their
Accept: list extremely short in order to reduce the number of bytes
they have to send in each HTTP connection. NCSA X Mosaic does take the
header seriously: it sends about an 800-byte Accept list. That costs
a significant fraction of a second on *every page fetch* across a modem
line. I've been seriously thinking of butchering my copy of Mosaic in
order to get rid of this nigh-useless overhead.
Thus, the nominal justification for image/pjpeg, content negotiation,
is a hopeless mess. By the time it could be fixed --- if it ever is
--- making a distinction between baseline JPEG and p-JPEG will be
unnecessary; essentially every JPEG-supporting browser will have p-JPEG
capability. (In fact, I will be fairly surprised if I hear of another
major browser version release without it.)
> put my money where my mouth is: I will bet that *regardless* of
> whether or not image/pjpeg is formally registered that more than 90%
> of browser makers that implement p-jpeg in the next six months will send
> image/pjpeg in their accept headers. Decision to be made on 1996-8-8).
If we examine the *last* six months, rather than the next six, you've
already lost the bet. (It's been just about six months since Spyglass
... not Netscape ... shipped the first widely-available p-JPEG-capable
browser.) If the situation is any different in the next six months, it
will be only because other browser vendors feel compelled to be
bug-compatible with Netscape, regardless of standards.
> Since p-jpeg is *not* interoperable with older non-p-jpeg
> implementations it *is* a new media subtype.
This is a highly debatable statement. The original MIME standards
failed to specify what subset of the full JPEG standard was implied by
image/jpeg. I can easily make JPEG files that are fully legal baseline
JPEG according to the JFIF and ISO JPEG standards, but will choke every
"JPEG-capable" browser in existence. There are numerous less drastic
sources of incompatibility --- for instance, IBM's old OS/2 Web browser
claimed to read JPEG, but failed to handle 1x1 subsampling, which is
generated by such commonly used applications as Photoshop.
The situation desperately needs to be cleaned up, and one of the items
on my to-do list is to write an RFC that will define image/jpeg with
some degree of precision. In the meantime, however, you will not get
far by arguing that p-JPEG is outside the recognized meaning of
image/jpeg. To the extent that there *is* any recognized meaning of
image/jpeg, it is "what the IJG decoder can read". Certainly it is not
"the intersection of what all allegedly JPEG-capable programs can read",
because (a) nobody knows exactly what that might be, and (b) it would
leave out an awful lot of files.
> It is *NOT* acceptable to serve p-JPEG blindly and pray that the browser
> at the other end will somehow be able display it. If that was my only
> choice - I just wouldn't use p-JPEG at all. I am sure that the many
> other web authors who make their *living* doing this feel the same.
Indeed, my original comment in this thread was that it's too early for
people to use p-JPEG on pages that must be widely accessible. But if
you take that hard a line, you have no defensible reason for using
any flavor of JPEG, because *you can't reliably tell from the Accept:
headers whether or not the browser supports it*. Are you planning to
serve GIFs to Internet Explorer users? Or maybe just plain text?
Content negotiation does not work well enough to justify the permanent,
long-run headache of a separate MIME type for p-JPEG.
There's a whole other line of argument against image/pjpeg, having to
do with the fact that it's not a good precedent for dealing with other
not-too-widely-used-at-present JPEG features. I can name at least five
others that might eventually need to be described by media type codes.
The cross product of these and pjpeg implies a need for sixty-four
distinct MIME subtypes if distinct subtypes are the representation.
This is clearly ridiculous. The right long-term answer is one MIME
type, image/jpeg, with MIME type parameters to call out non-baseline
features. But MIME parameters are even less widely supported than
correct content negotiation on plain subtypes. In the meantime,
Netscape has done the world no service by going off half-cocked with
an unregistered MIME type.
regards, tom lane
organizer, Independent JPEG Group
Paul Rohr
Lane) wrote:
> snow...@ns.viet.net (Jerry Franz) writes:
> > I know that at least one other popular browser (Spyglass Mosaic) also
> > sends a image/pjpeg accepts header. I am not aware of any other
> > popular browser that *can* render p-jpeg as they download
>
> You clearly haven't a clue about the state of p-JPEG support. Check
> the JPEG FAQ for the names of some other p-JPEG-capable browsers.
> (The FAQ doubtless doesn't list 'em all, either.)
>
> The only non-Netscape p-JPEG-capable browser that I have installed at
> this moment is Microsoft Internet Explorer (Mac 2.0b2). It does not
> send Accept image/pjpeg; indeed its accept header doesn't mention any
> image/* types at all. (I just verified this with a CGI test page.)
> Since MSIE is a Spyglass derivative, this strongly suggests that other
> flavors of Spyglass Mosaic don't send Accept image/pjpeg either.
> Exactly what version of Spyglass are you referring to above?
> Have you *checked* what it sends?
Tom's right. Before releasing Spyglass Mosaic 2.1 last September with
Progressive JPEG support turned on, we participated in the discussion
on the IJG's mailing list on this very issue.
As per that discussion, we send Accept: image/jpeg.
--
Paul Rohr
Software Engineer
Spyglass, Inc.
Make the Net Work(tm)
Scott Furman
> This issue was discussed to death last summer, and the consensus was
> that it was a band-aid to fix a short-term problem. If content type
> negotiation were workable and widely used, there would have been more
> of a motivation to set up image/pjpeg as a distinct type. But the fact
> is that content type negotiation *doesn't* work. Far too few browsers
> send useful Accept: lists; most rely on Accept: */*. (Netscape is one
> of the big offenders, btw. It is amusing to note that there is *no*
> overlap between the Accept: lists of Netscape and Internet Explorer
> except for */*. Netscape calls out four or so image/xxx types, and
> leaves all else to */*; IE calls out four or five audio/xxx types,
> and leaves the rest to */*. There's no way that you can intelligently
> serve the right file type to both these major browsers if you rely only
> on their Accept: headers.)
>
This is not quite true. Netscape sends different accept headers
depending on whether or not the requested item is an inline image,
i.e. requested using an IMG tag from within an HTML document.
The */* is *not* sent in the inline image case. Rather, only the
specific image types supported are sent, i.e. image/gif, image/jpeg.
image/pjpeg. Some other browsers do, incorrectly, send */* in the
accept headers for inline image requests.
-Scott
Snowhare
Nothing above this line is part of the signed message.
In article <TGL.96Fe...@netcom21.netcom.com>,
Tom Lane <t...@netcom.com> wrote:
>snow...@ns.viet.net (Jerry Franz) writes:
>> Tom Lane <t...@netcom.com> wrote:
>>> snow...@xmission.xmission.com (Snowhare) writes:
>>>> Netscape (at least) sends an Accept header with
>>>> 'image/pjpeg' that can be used efficiently to negotiate between jpeg and
>>>> p-jpeg. I am now coverting some of my sites to take advantage of this
>>>> using Apache's content negotiation features.
>>>
>>> Actually, I'd entreat you not to do that, as it will certainly break your
>>> pages on every other browser.
>
>> Depends on how you define 'break'. In this context, for me 'break' means that
>> a browser gets a media type they cannot display. Detecting on image/pjpeg
>> insures that this *highly* undesirable event does not happen. The choice
>> is not between 'right' negotiation and 'wrong' negotiation. It is between
>> serving progressive jpegs to the two browsers I know provide image/pjpeg
>> in their request headers (with non-progressive jpeg going to everyone else)
>> and serving non-progressive jpeg to *everyone*.
>
>That means that you fail to serve progressive JPEG to most of the
>p-JPEG-capable browsers out there. If you are dead set on having your
>pages show non-broken images to every browser without any user interaction,
>fine; that's a legitimate goal. But I suggest you forget JPEG entirely and
>use GIF. Much safer. As shown below, if you rely on Accept: headers then
>you will not be sending *anything* to some large fraction of browsers.
Ummm.. I take it you are not very familiar with content negotiation in
practice. *In practice* - if a browser sends no Accepts header at all or
sends nothing that will match exactly - a choice is made for them. Apache
unfortunately makes the worst possible choice under most circumstances,
however. I am re-writing the content negotiation module to correct that
situation.
>
>>> Using image/pjpeg without registration is a clear violation of the
>>> Internet media type standards. AFAIK, Netscape 2.beta is the only
>>> p-JPEG-capable browser that will send this illegal type code.
>
>> I know that at least one other popular browser (Spyglass Mosaic) also
>> sends a image/pjpeg accepts header. I am not aware of any other
>> popular browser that *can* render p-jpeg as they download
>
>You clearly haven't a clue about the state of p-JPEG support. Check
>the JPEG FAQ for the names of some other p-JPEG-capable browsers.
>(The FAQ doubtless doesn't list 'em all, either.)
Not to start trading insults - but you are wrong about it being a
violation of the relevant standard. Read the content negotiation section
of the 1.1 HTTP draft carefully. Registration is *NOT* required - only
encouraged. Interestingly, x-types are *not* encouraged.
>The only non-Netscape p-JPEG-capable browser that I have installed at
>this moment is Microsoft Internet Explorer (Mac 2.0b2). It does not
>send Accept image/pjpeg; indeed its accept header doesn't mention any
>image/* types at all. (I just verified this with a CGI test page.)
>Since MSIE is a Spyglass derivative, this strongly suggests that other
>flavors of Spyglass Mosaic don't send Accept image/pjpeg either.
>Exactly what version of Spyglass are you referring to above?
>Have you *checked* what it sends?
I made that statement in error. A consequence of the Apache (mis)feature
I alluded to above. Apache was sending pJPEG to browsers that *didn't*
request it because of the '*/*' "match".
>I believe that Netscape 2.0x is the only major browser that sends
>image/pjpeg, but I have no direct way of proving this. (Anybody
>know of a browser test site that keeps track of Accept: headers?)
I just ran a test (I maintain several sites that are ideal for testing -
volume in the tens of thousands of hits per day range). I found *no*
other browser that sends a image/pjpeg header besides Netscape 2.0x and
Netscape Gold. One sends image/x-pjpeg (Mosaic 2.6 for X11) and one
sends image/pjeg (SPRY_Mosaic).
The only ones that did not request at least one 'image' type were
ArchitextSpider, CERN-LineMode, Lynx, Netmanage Chameleon WebSurfer, Opera,
PipeWinWeb, FFiNet, and WebWatch. NetManage Chameleon WebSurfer
requested '*', Opera requested '*/*'. ArchitextSpider, FFiNet and
PipeWinWeb requested nothing.
Relevant percentages (from 442K hit database)
ArchitextSpider: 0.125%
PipeWinWeb: 0.031%
CERN-LineMode: 0.005%
Lynx: 2.03%
NetManage Chameleon WebSurfer: 0.388%
Opera: 0.002%
FFiNet: 0.016%
WebWatch: 0.007%
Lynx and CERN-LineMode are of course irrelevant to the issue as text
only browsers. As is ArchitextSpider as a robot. All together, the rest are
not even 0.5%.
[lots of very cogent stuff deleted]
>
>> It is *NOT* acceptable to serve p-JPEG blindly and pray that the browser
>> at the other end will somehow be able display it. If that was my only
>> choice - I just wouldn't use p-JPEG at all. I am sure that the many
>> other web authors who make their *living* doing this feel the same.
>
>Indeed, my original comment in this thread was that it's too early for
>people to use p-JPEG on pages that must be widely accessible. But if
>you take that hard a line, you have no defensible reason for using
>any flavor of JPEG, because *you can't reliably tell from the Accept:
>headers whether or not the browser supports it*. Are you planning to
>serve GIFs to Internet Explorer users? Or maybe just plain text?
Text won't work because I am not aware of *any* browser that can handle
text/plain where it expects an image. And IE explictly asks for image/jpeg.
But to answer the more general question: the ability to support image/gif
and image/jpeg (non-progressive) are considered baseline features in
browsers today. I am aware of only ONE graphical browser with a significant
user base (MacWeb 1.x - at 0.1% in my logs) that does not support inline
jpeg. A graphic format is acceptable as a base to me if I lose more text
only browsers (at 2% of the market) than graphic browsers. This means *either*
GIF or non-progressive JPEG.
>Content negotiation does not work well enough to justify the permanent,
>long-run headache of a separate MIME type for p-JPEG.
I disagree. ;-). It *can* be made to work - but not by people who use
server software out of the box. Even with Apache I will have to make
changes to the content negotiation module to get reasonable behavior. I
believe this to be a consequence of the 1.1 HTTP draft thinking of the
quality in a one dimensional fashion. That one image is 'lower quality'
than another does not mean that absent *any* hint as to what format is
prefered by the browser I should serve the 'highest' quality one - which
is what the draft says to do.
Benjamin Franz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMR+Oq+jpikN3V52xAQHl3gP/dwdaOsiP+Wjq/8T+//jWrZDsK6Ee9DPC
x2rNstvvlvrlabwrdroCWkA+CQ3B//BwaWg9A/6dpdnlyf564DrAuWjJ/swtHo4P
SAy4DmUXsRxCqv+Ka4MyTJOxcjpY+TUQdvHnmmvk75sSNc2O9tufwUkozBsW66v7
4BrxwVHXN8Y=
=fXi9
-----END PGP SIGNATURE-----
Snowhare
Nothing above this line is part of the signed message.
In article <paul-11029...@munter.spyglass.com>,
Paul Rohr <pa...@spyglass.com> wrote:
>In article <TGL.96Fe...@netcom21.netcom.com>, t...@netcom.com (Tom
>Lane) wrote:
>> snow...@ns.viet.net (Jerry Franz) writes:
>> > I know that at least one other popular browser (Spyglass Mosaic) also
>> > sends a image/pjpeg accepts header. I am not aware of any other
>> > popular browser that *can* render p-jpeg as they download
>>
>> You clearly haven't a clue about the state of p-JPEG support. Check
>> the JPEG FAQ for the names of some other p-JPEG-capable browsers.
>> (The FAQ doubtless doesn't list 'em all, either.)
>>
>> The only non-Netscape p-JPEG-capable browser that I have installed at
>> this moment is Microsoft Internet Explorer (Mac 2.0b2). It does not
>> send Accept image/pjpeg; indeed its accept header doesn't mention any
>> image/* types at all. (I just verified this with a CGI test page.)
>> Since MSIE is a Spyglass derivative, this strongly suggests that other
>> flavors of Spyglass Mosaic don't send Accept image/pjpeg either.
>> Exactly what version of Spyglass are you referring to above?
>> Have you *checked* what it sends?
>
>Tom's right. Before releasing Spyglass Mosaic 2.1 last September with
>Progressive JPEG support turned on, we participated in the discussion
>on the IJG's mailing list on this very issue.
>
>As per that discussion, we send Accept: image/jpeg.
This was my mistake - I mis-interpretted the fact Apache was sending
the p-JPEG version to Spyglass to imply that Spyglass Mosaic was sending
an image/pjpeg in the Accept: line. Closer investigation has revealed a
serious problem with the implementation of content negotiation in Apache
that will require me to rewrite that module before I can use it
effectively. (As a by-effect of that investigation I have the most
amazing list of Accepts: headers from many different browsers. There are
an amazing number of ways to produce accepts lines. Omni-web
requests image/jpeg four times in a row, Mosaic 2.6 for XWindows
requested image/x-pjpeg, and SPRY_Mosaic requests image/jpeg
twice along with image/x-pjeg. More than one browser requests "*" (and
nothing else).
As written - Apache appears to follow the recommendation that a '*/*' match
give the *highest* quality possibility when no exact match is made (with
its tie-breaking code producing non-deterministic results). As a
consequence - it virtually guarantees that content that cannot be
displayed will be sent to many browsers (most notably NCSA Mosaic 2.0
for Windows). This is because the *highest* quality items are usually in
the *least* common formats.
Just consider a document available as Postscript, HTML and text. The
Postscript document is the *highest* quality - but the most unlikely to
be displayable (there are *DAMN* few browsers that can display Postscript
internally). Ditto for PNG, p-JPEG, JPEG and GIF. The highest quality
is the least likely to be displayable by a random user agent *in general*.
This seems to be another case where the standard shoots itself in the
foot in the face of real life implementation.
In order to make content negotiation work, I am going to have to re-write
the module for content negotiation to allow matching 'Accept: */*' to an
explicit default in the negotiation map files. Until then - p-JPEG will not
be on *anything* I intend for customer sites. So for the next few days -
I am not serving pJPEG at all.
I am very troubled though by the belief evinced here that I should not
give pjpeg to *anyone* unless I am willing to take the risk that I will give
browsers that can't handle pjpeg a pjpeg file. Bluntly - *right now*
Netscape 2.0 is 30% of the browser base. 40% is Netscape 1.1/1.2 (which
most definitely *can't* display pJPEG). I *CAN* (after some rewriting of
the content negotiation module for Apache) guarantee that I won't serve
p-JPEG to a non-PJPEG capable browser.
*AT WORST* this means I will give a non-progressive JPEG to a browser that
could handle a pJPEG (a number no higher than 30% of installed browsers -
and probably much lower). In several months (when the *installed* base of
browsers can be trusted to nearly universally handle pJPEG) I will take
off the limitation. It is called a transistion strategy. And with care it
is *optimal* for more than 70% of the browsers in use - a number that is
likely to remain quite stable for the next several months. Give me an
alternative that is optimal for *more* than 70% of the browsers (and
not fatal to any) and I will use it instead.
Benjamin Franz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMR92qejpikN3V52xAQE1jgQAkVnaaM2UncIXlK/NVgh1thXMmuya2N6S
ss4AxkxXl4deeyF6wzxXUnv/V/QtN76vUy88HXxKAK8Vdqb7DlYM8YjA+ytJ1cck
LY4Wa2XlNYPxhRfvBKZlVud7p8sgNikfcMNoxPZvoopIYOPBy46i63BuWV45HitQ
pT/tLjFxGa0=
=xLp1
-----END PGP SIGNATURE-----
Tom Lane
> Tom Lane <t...@netcom.com> wrote:
>> That means that you fail to serve progressive JPEG to most of the
>> p-JPEG-capable browsers out there. If you are dead set on having your
>> pages show non-broken images to every browser without any user interaction,
>> fine; that's a legitimate goal. But I suggest you forget JPEG entirely and
>> use GIF. Much safer. As shown below, if you rely on Accept: headers then
>> you will not be sending *anything* to some large fraction of browsers.
> Ummm.. I take it you are not very familiar with content negotiation in
> practice. *In practice* - if a browser sends no Accepts header at all or
> sends nothing that will match exactly - a choice is made for them. Apache
> unfortunately makes the worst possible choice under most circumstances,
> however. I am re-writing the content negotiation module to correct that
> situation.
Sorry, I phrased that poorly. By "not sending anything" I meant
"not sending anything reasonable".
> I just ran a test (I maintain several sites that are ideal for testing -
> volume in the tens of thousands of hits per day range). I found *no*
> other browser that sends a image/pjpeg header besides Netscape 2.0x and
> Netscape Gold.
As I suspected.
> One sends image/x-pjpeg (Mosaic 2.6 for X11) and one
> sends image/pjeg (SPRY_Mosaic).
NCSA X Mosaic's header refers to some private thingie they are working on
with Kodak --- the "p" stands for "PhotoCD" not "progressive". In 2.7b2
they have changed it to "x-pcd-jpeg" so as to reduce the chance of
confusion with Netscape's usage. However, at the time these decisions
were being made last summer, 2.6 was current. I suspect that Netscape
might have chosen to send image/x-pjpeg if they hadn't been aware of
Mosaic's usage. Oh well.
"pjeg"? Really? Are you sure your script didn't log a corrupted message?
If it is a misspelling on Spry's part, it seems at least as likely to be
a typo for "jpeg" as "pjpeg" (swapped chars vs. dropped char).
> The only ones that did not request at least one 'image' type were
> ArchitextSpider, CERN-LineMode, Lynx, Netmanage Chameleon WebSurfer, Opera,
> PipeWinWeb, FFiNet, and WebWatch.
I observe that Internet Explorer for Mac (2.0b2) does not send any image/*
types either. Either your sample didn't happen to include this browser,
or one of us is mistaken.
>> Content negotiation does not work well enough to justify the permanent,
>> long-run headache of a separate MIME type for p-JPEG.
> I disagree. ;-). It *can* be made to work - but not by people who use
> server software out of the box. Even with Apache I will have to make
> changes to the content negotiation module to get reasonable behavior.
I think you have missed my point here. I did not say that content
negotiation could never work. I said that *right now* it does not work
well enough to justify putting a permanent glitch into the MIME
description of JPEG. And your comments prove my point.
Both browser and server changes will have to occur before content
negotiation can be really workable and widely used. I hope to see
that happen, but it cannot possibly happen before the problem of
distinguishing baseline JPEG from p-JPEG ceases to be a significant
problem. Putting a band-aid on the MIME type is thus a short-term
hack: no long-term benefit and darn little short-term benefit either.
I notice you didn't respond to my point about media type parameters
versus a plethora of subtypes. I would be interested to know what
you think about that issue.
Bottom line: my feeling is that "image/pjpeg" is a crock that should be
ignored. I would like to see the formal description of "image/jpeg"
tightened up and extended with parameters to describe non-baseline-JPEG
extensions. There are several things in the recently finished JPEG Part 3
spec that could usefully be handled that way, and we have some breathing
room to try to handle them in a more orderly fashion this time 'round.
I guess the real question is whether servers will be taught to handle
content negotiation based on media type parameters within the next few
months.
Bennett Todd
Snowhare <snow...@xmission.xmission.com> wrote:
>[...]
>Lynx and CERN-LineMode are of course irrelevant to the issue as text
>only browsers. As is ArchitextSpider as a robot. All together, the rest are
>not even 0.5%.
Lynx has no trouble displaying jpegs, gifs, PostScript, and everything
else I've tried to look at with it. It spawns external viewers, using the
mailcap and mime.types databases for the purpose. Works like a champ. Are you
_positive_ you have any idea what you're talking about?
I'm very, very glad I use Apache the way it comes; I don't want to go in and
hack the sources to my http daemon every time web browsers change. Content
type negotiation is a clever idea that turned out not to be necessary, so
people don't do it, so it doesn't work.
Happily, since it is's neither needed nor used, we can ignore the whole mess!
-Bennett
Alan J. Flavell
>> Are you
>>_positive_ you have any idea what you're talking about?
>
>Yes. I am positive.
...
> And we
>are talking about *INLINE* images displayed *by the browser*. If you get
>into the realm of 'but I can manually type in the URL for the graphic
>and launch a viewer'
Are you positive? You evidently _don't_ know that Lynx-FM can do
this with a couple of keystrokes, and certainly nobody would need to
"manually type in the URL", even if they'd forgotten that the
keystrokes are available (ever heard of cut and paste?).
Whether you are right or wrong that most users of Lynx don't have
access to X Windows, I could not say. I often use Lynx (although
not as my only browser, but I do often use it) from a host session
in an X window, as it happens. But I never claimed to be typical.
---
Alan