Closed Bug 96428 Opened 23 years ago Closed 22 years ago

PGP signature displayed as source for an empty HTML document

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 184144

People

(Reporter: gward, Unassigned)

References

(
URL
)

Details

(Keywords: compat) 

The referenced URL is to a small text file containing a PGP signature.  Here's
what I get accessing the URL using the lwp-request program:

GET http://www.mems-exchange.org/software/files/quixote/Quixote-0.3.tar.gz.asc
--> 200 OK
Connection: close
Date: Wed, 22 Aug 2001 15:11:41 GMT
Accept-Ranges: bytes
Server: Apache/1.3.19
Content-Encoding: x-gzip
Content-Length: 228
Content-Type: text/plain
ETag: "f97a-e4-3b20f227"
Last-Modified: Fri, 08 Jun 2001 15:41:27 GMT
Client-Date: Wed, 22 Aug 2001 15:10:26 GMT
Client-Peer: 132.151.1.12:80

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQA7IPIjkk7iDRL+RlcRAmIvAJ9QE5t3FzIrXzhh5QnM6bHq5j/DMgCfduah
2w1OHqeIiFEPJsIvAHtvOIg=
=+PGj
-----END PGP SIGNATURE-----

This looks fine to me, but the "Content-encoding" header could be problematic. 
Hmmm.  When I access this URL in Mozilla 0.9.3, it displays this text:

<html><body></body></html>

If I "view source" for this document, it displays exactly the same text.
I would expect Mozilla to either display the PGP signature in that file, or to
complain that the content isn't really gzip-encoded!  (And maybe then display
the actual content.)
I see this on Win2k 20010820.

OS should be All/All
This looks like a misconfigured webserver. Should it go to Tech Evangelism?
Note that I am one of the admins of the webserver in question (I'm the bug's submitter).  I am aware that the webserver is subtly misconfigured; it should not be claiming that this file (a PGP signature in ASCII armor) is gzip-encoded.  However, Mozilla's response to this particular mis-configuration is bizarre.  I can see two reasonable responses for Mozilla to make: 1) throw up an error dialog telling the user that the document *claims* to be gzip-encoded, but Mozilla was unable to decode it, or 2) after gzip-decoding fails, ignore the claimed encoding and just interpret the document as plain text.  This seems to be what both Opera and Konqueror do.If I edit the webserver's config (it's Apache: I just comment out the "AddEncoding x-gzip gz" line), Mozilla handles this document fine.  I'm not claiming the webserver is acting correctly; clearly it's in the wrong.  But Mozilla is not handling this particular example of webserver misconfiguration very well!
Over to networking
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: doronr → tever
darin, please comment about the servers response in question.
interesting... there's nothing at all unusual about the server response.  when i
try it today, i get a slightly different response... Content-Encoding: gzip
instead of Content-Encoding: x-gzip, but that should never have been a problem
anyways.  i'll need to do some more poking around to see what the problem with
this one is.

-> reassigning to self
Assignee: neeti → darin
OK, it turns out that someone above netlib is canceling the http channel:

  nsHttpTransaction::Cancel [this=86e5f80 status=80004005]

perhaps the parser??

-> parser
Assignee: darin → harishd
Component: Networking: HTTP → Parser
QA Contact: tever → moied
Darin: AFAIK, parser doesn't do any such cancellation.
well, if the parser returned NS_ERROR_FAILURE from OnStartRequest or
OnDataAvailable, it would be treated equivalently to a call to
Cancel(NS_ERROR_FAILURE).  perhaps that would explain this?
Greg: When I loaded the above URL in IE it rendered blank too. Is that the case
or am I seeing things? 

<sigh>Not sure why this bug landed on my plate</sigh>. There is nothing much
parser can do if some one wants the parser to be stopped. 
I don't have access to IE, so I can't vouch for how it handles this page.

Opera (6.0 TP3) and Konqueror 2.2.1 (both under Linux -- Debian
unstable) can deal with this document.  That is, they don't get all
confused by the incorrect "Content-encoding" header; they go ahead and
display the document as-is without any attempt to gunzip it.

This doesn't look like a parser bug. 

--> nobody
Assignee: harishd → nobody
bouncing out of parser per harishd
Component: Parser → Browser-General
Keywords: compat
Dupping forward to bug with more analysis and discussion.

*** This bug has been marked as a duplicate of 184144 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.