128909 - File: URL's w/ an illegal drive name (4th field) do not "file not found" error (Win + Mac OS)

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[benc]

Mozilla 0.9.8 - Win98.

STEPS:

file:///C:/Program%20Files -> displays directory listing correctly
file:///G:/Program%20Files -> displays error (file not found) correctly)

file:///notadriveletter/notafilename -> no error dialog

EXECTED BEHAVIOR:
File URL's that do not retrieve a file from local disk should always return an 
error to the user.

Comment 1

[Tom Everingham]

ben is this the same as bug# 65102

Comment 2

[Tom Everingham]

sorry, i meant bug# 70871

Comment 3

[Tom Everingham]

ben says no not a dupe :-) -> file

Comment 4

[benc]

Affects Mac OS X and classic, commercial build 2002-05-12-17

Seems like some of the aspect of drive volumes is common to non-UNIX platforms.

Comment 5

[Doug Turner (:dougt)]

The docshell needs to check for a invalid drive/url when it does LoadURI.  It is
already trying to "fixup" the url.  

Maybe the fix should be in FileURIFixup?


nsDefaultURIFixup::FileURIFixup
nsDefaultURIFixup::CreateFixupURI
nsDocShell::CreateFixupURI
nsDocShell::LoadURI

Comment 6

[Adam Lock]

Shouldn't it be netwerk and the file protocol that complains about invalid
drives? How is docshell supposed to know except by opening a channel and
checking for errors?

Comment 7

[Michael Lefevre]

*** Bug 152407 has been marked as a duplicate of this bug. ***

Comment 8

[benc]

This "cannot find the drive" problem seems to happen in Mac OS X on the Mozilla
1.0.1 branch

Comment 9

[Adam Lock]

-> Netwerk

Probably the file protocol handler needs to test if the specified volume exists
or not.

Comment 10

[Doug Turner (:dougt)]

We are not talking about a volume not existing.  We are talking about the drive
letter part of the URL not containing a : or |.  The URL is bad.

The real problem is that we discover that this is a problem when we ask for the
underlying nsIFile inside the init of the file channel.  From there, we return
an error.  Docshell doesn't handle this case.... nor it should right? Maybe this
should be pushed down until when some calls AsyncOpen|Open.  

Comment 11

[Doug Turner (:dougt)]

Attachment: patch v.1

Comment 12

[Doug Turner (:dougt)]

Attachment: patch v.1 (with correct MIME type)

Comment 13

[Darin Fisher]

Comment on attachment 99989 [details] [diff] [review]
patch v.1 (with correct MIME type)

>+    // if we support the nsIURL interface then use it to get just
>+    // the file path with no other garbage!
>+    nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(mURI, &rv);
>+    if (NS_FAILED(rv)) {
>+        // this URL doesn't denote a file
>+        return NS_ERROR_FILE_NOT_FOUND;
>+    }

uhm, the URL created by the file protocol handler had better implement
nsIFileURL.  if not, this is a major problem.  this should really output
some kind of debug warning.  maybe NS_ENSURE_TRUE would be better?!


>+    if (NS_FAILED(rv)) {
>+        
>+        mStatus = rv;
>+
>+        nsCOMPtr<nsIStreamListener> asyncListener;
>+        NS_NewAsyncStreamListener(getter_AddRefs(asyncListener), this, NS_CURRENT_EVENTQ);
>+        if(asyncListener) {
>+            (void) asyncListener->OnStartRequest(this, ctxt);
>+            (void) asyncListener->OnStopRequest(this, ctxt, rv);

NS_NewAsyncStreamListener is deprecated.  use NS_NewRequestObserverProxy
instead since
all you want to do is call OnStartRequest/OnStopRequest.


> NS_IMETHODIMP
> nsFileChannel::GetContentType(nsACString &aContentType)
> {
>+    nsresult rv = EnsureFile();
>+    if (NS_FAILED(rv)) {
>+        mContentType = NS_LITERAL_CSTRING(UNKNOWN_CONTENT_TYPE);
>+        return NS_OK;
>+    }

you shouldn't have to do this.	it's not valid to query the content-type
or content-length of a channel until after you have received OnStartRequest.
in other words, these methods should return NS_ERROR_NOT_AVAILABLE if
there is no underlying file.

Comment 14

[Doug Turner (:dougt)]

Attachment: patch v.2

what darin said.

Comment 15

[Darin Fisher]

Comment on attachment 99997 [details] [diff] [review]
patch v.2

r/sr=darin

Comment 16

[neeti]

Comment on attachment 99997 [details] [diff] [review]
patch v.2

r=neeti

Comment 17

[Doug Turner (:dougt)]

Checking in nsFileChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/file/src/nsFileChannel.cpp,v  <-- 
nsFileChannel.cpp
new revision: 1.127; previous revision: 1.126
done
Checking in nsFileChannel.h;
/cvsroot/mozilla/netwerk/protocol/file/src/nsFileChannel.h,v  <--  nsFileChannel.h
new revision: 1.55; previous revision: 1.54
done

Comment 18

[Doug Turner (:dougt)]

this caused tb problems and I backed it out... 

Comment 19

[Doug Turner (:dougt)]

fixed for really this time... :-)

Comment 20

[Jimmy Lee]

Build: 2002-10-22-08-trunk

Receiving error as expected for file URL that does not retrieve file(s) from
local disk.  Marking Verified!

Comment 21

[John Cowan]

This bug is *not* fixed in either Firefox 1.0.7 for Win32 or Firefox 1.5 beta
for Win32, and should be reopened.  See also #207275, which is a different but
related bug.  --John Cowan <[e-mail]>