Closed Bug 56498 Opened 24 years ago Closed 23 years ago

free (beer) alternatiff plugin doesn't render tiff images correctly at US patent office site.

Categories

(Core Graveyard :: Plug-ins, defect, P3)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED INVALID
Future

People

(Reporter: griffith, Assigned: serhunt)

References

()

Details

The alternatiff plugin for rendering tiff images is very useful for viewing the
tiff images of US patents at the USPTO site.  It does not work under Mozilla
M18/NT, as you can check by installing the plugin and trying to view the above
URL.  Install the same plugin with Netscape and check the same URL to see the
correct behavior.  Note that the most current versions of the plugin are
available from http://www.mieweb.com/alternatiff/.  The most current versions
require you to register them the first time that they are used.  I have an older
version that doesn't require this - it also doesn't work under Mozilla M18.  I
can provide the older version and some screenshots showing the problem.  If I
can figure out how to attach them to this bug report, I will.
I've been unable to pin down this problem, but I'm convinced it's a bug in 
Mozilla. Here are some things I've noticed. The behavior has been fairly 
consistent, but with the occasional bit of flakiness, possibly caused by a slow 
server.

- The plugin in question works fine on other web sites.

- This is not specific to any particular TIFF plug-in, and probably not specific 
to the TIFF file type, either. Mozilla is for some reason failing to determine 
the content type of the TIFF document, and therefore not loading a TIFF plug-in 
at all.

- If you figure out the URL of the TIFF image (from the EMBED tag in the 
source), append "&xx=x.tif" to the end of it, and go directly to it, then it 
works. This is a bit scary, because a browser should never ever use an HTTP URL 
to determine a file type, *except* in the very rare case that the document did 
not have a "Content-Type" header. The documents in question do have this header. 
Should I give Mozilla the benefit of the doubt and assume that somehow it is 
losing track of the header, and only then resorting to the emergency backup 
"guess the type by the extension" method?

- If, instead of the patimg[*].uspto.gov hostname, you use the IP address, or 
the alias potw[*].uspto.gov, then it works. Say what??!!?? Could Mozilla be 
doing something really absurd like searching for certain strings of characters 
("img"?) in the hostname, and if it finds them, ignoring the "Content-Type" 
header? That's just too bizarre, but even then it can't be that simple, because:

- I cannot reproduce this problem on my own server. Even if I give it a hostname 
of "patimg1.(mydomain)", and create URL that's otherwise exactly the same as one 
that failed, it works fine.
Confirmed with 111004 build on NT.  Plugin doesn't seem to work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
The USPTO has modified their site to work around this. Presumably, the bug still 
exists in Mozilla, but I do not know any way to test it.
Marking invalid. Please reopen if there is a testcase.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Target Milestone: --- → Future
spam : marking invalid bugs 'verif'. reopen if u disagree, reporter!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.