272802 - mailcap MIME type comparison done in case-sensitive way

Status: RESOLVED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Chad S. Lauritsen]

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

I have registered a handler for "application/octect-stream" in my mailcap file.
I received a email with an attachment of type "Application/Octet-stream"
(according to view source). The helper app selection dialog was then presented
to me to select a handler for type "application/octet-stream". If I add
Application/Octet-stream to my mailcap, then the hander is found. It seems
impractical to add all permutations of case to mailcap. I don't know the RFCs on
this (if any), but shouldn't mozilla do the comparison of content-type in a
message to mailcap file entry in a case-insensitive manner?

Reproducible: Always
Steps to Reproduce:
1. Send an email with 2 attachments, on of type application/octet-stream and one
of type Application/Octet-stream.
application/octet-stream; 
2. Add one entry to /etc/mailcap:
application/octet-stream; xclock
3. Open both attachments from mozilla

Actual Results:  
The attachment with type application/octet-stream will bring up dialog with 3
choices: launch with xclock, open with user-specified, or save to disk. 

The attachment with type Application/Octet-stream will bring up dialog with 2
choices: launch with user-specified, or save to disk. 

Expected Results:  
Both attachments should launch with the 3-choice dialog box.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Odd.  I made all string comparisons in the mailcap code case-insensitive when I
wrote it....  See
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/unix/nsOSHelperAppService.cpp#1065
for the code that compares the type listed in the file to the type we were
given, and note the use of nsCaseInsensitiveStringComparator().

So either case-insensitive string comparisons are broken altogether, or this is
a bug in higher-level code... (well, the fact that we get different case out of
a channel indicates a higher-level bug no matter what, but the code should be
handling that too).

Chad, could you possibly run:

  env NSPR_LOG_MODULES=HelperAppService NSPR_LOG_FILE=/tmp/log.txt mozilla

then reproduce the bug, and attach the /tmp/log.txt file that's generated to
this bug?

Comment 2

[Chad S. Lauritsen]

I turned on logging, which brought to light that I had mis-diagnosed the
problem. The application/octet-stream handler was in fact being found even with
a source mime type of Application/Octet-stream. The problem was with the handler
I had registered for application/octet-stream 

Marking as invalid. Apologies and thanks to Boris for your responsiveness.