215866 - Unknown gopher document types give strange error message

Status: RESOLVED FIXED

(Core :: Networking, defect, P4)

Description

[Thomas Thurman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030715 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030715 Mozilla Firebird/0.6

Unknown document types in gopher: URLs cause a new, blank page to be displayed
containing only the words

  3Unknown Selector String .

which is strangely formatted. I would have expected no "3" and no space before
the final full stop.

(For consistency, this should really be a matter for an error dialogue box, as
seen when an unknown protocol is found in a URL.)

FYI, the document type "h" is in commonly use (it means text/html), but isn't
one of the original set listed in RFC 1436. It would be good if Moz supported
it, but that's not the point of this bug: the point is the strange error message.

Reproducible: Always

Steps to Reproduce:
1. Go to gopher://sipb.mit.edu/
2. Click the last entry, "New e-mail directory (http://usenet-addresses.mit.edu/)"

Or just go to gopher://sipb.mit.edu/hH:usenet-addresses.html

Comment 1

[Simon Paquet [:sipaq]]

Moving over to Networking

Comment 2

[Boris Zbarsky [:bzbarsky]]

Actually, that's not an error message generated by Mozilla.  That's the data
returned by the server.  Just try replacing the 'h' by a '0' in the URL and see
that that does not affect the data (although it does change the rendering a bit,
since we render it as HTML, not plaintext).

In any case, I'll attach a patch to add support for 'h'; I'm losing my net
connection later tonight, so someone else will need to drive the patch in.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: patch

Comment 4

[Bradley Baetz (:bbaetz)]

Comment on attachment 129629 [details] [diff] [review]
patch


>@@ -731,13 +732,13 @@ nsGopherChannel::PushStreamConverters(ns
>                    listener,
>                    mUrl,
>                    getter_AddRefs(converterListener));
>             break;
>         }
>         if (NS_FAILED(rv)) return rv;
>-    } else if (mType=='0') {
>+    } else if (mType == '0' || mType == 'h') {
>         // Convert general file
>         rv = StreamConvService->AsyncConvertData(NS_LITERAL_STRING("text/plain").get(),
>                                                  NS_LITERAL_STRING("text/html").get(),
>                                                  listener,
>                                                  mListenerContext,
>                                                  getter_AddRefs(converterListener));

This is wrong. 0 is a text file type, but we pass it through a convertor so
that urls are linkified, and so on (which is why we return an http content
type).

That shouldn't be needed for things which really are HTML.

Comment 5

[Jan Ruzicka]

can this one be moved to status 'new'?
The bug is showing as described.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: So this is all it needs, then?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 146392 [details] [diff] [review]
So this is all it needs, then?

Assuming I understand the situation correctly....

Comment 8

[Bradley Baetz (:bbaetz)]

Comment on attachment 146392 [details] [diff] [review]
So this is all it needs, then?

Probably. Don't forget to test it :)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Any suggestions on how to test past loading a few gopher sites with /h and
making sure they run through our HTML parser (which they do)?

Comment 10

[Darin Fisher]

Comment on attachment 146392 [details] [diff] [review]
So this is all it needs, then?

rs=darin

Comment 11

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed.