Closed Bug 102737 Opened 23 years ago Closed 22 years ago

file:// empty files (0 bytes) display "<html><body></body><html>"

Categories

(Core :: Networking: File, defect)

Product:
Core
Component:
Networking: File
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: benc, Assigned: rpotts)

References

Details

(Keywords: testcase, Whiteboard: notfixed in 094)

Attachments

(1 file, 1 obsolete file)

new patch that doesn't hit the bug in the scanner...
1.19 KB, patch
harishd
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Mozilla 0.9.4 all plats:

Create a zero byte file w/ touch (Mac OS X) or "New | Text Document" (Win).

Reference file as file URL in Location bar (or Open via "File | Open File..."

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

is displayed.

EXPECTED:
Some sort of friendly error message, or display nothing...

If this this needs to be fixed elsewhere, please create a new bug and link via a
dependency. Bug 90775 probably has similar problems, but I want to keep my bug
for my testcases.
+testcase
Keywords: testcase
Summary: file: empty files appear as <html><body></body><html> → file: empty files (0 bytes) display "<html><body></body><html>"

*** This bug has been marked as a duplicate of 71635 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Oops.. i dup'ed this - it's been reported several times.
Please do reopen if you want to keep the bug for your testcases.
REOPEN:
no problem! dependency is in.
Status: RESOLVED → REOPENED
Depends on: 71635
Resolution: DUPLICATE → ---
These all probably would be fixed by the fix in bug 19073, which has a patch,
and is waiting on mscott for comment.
this sounds like a dup of 19073.  bbaetz?
Assignee: dougt → bbaetz
Status: REOPENED → NEW
dougt: No, here the file exists. This is the nothing == about:blank problem

Back to you :)
Assignee: bbaetz → dougt
There is some speculation in bug 98203 that 98203 causes this one (or maybe
that's just what triggers this bug most frequently).
This is almost certainly not related to bug 98203
This is a result of bug 72679.  Reassigning to Rick.
Assignee: dougt → rpotts
well, maybe not completely.  We still need something like the following. 
however, I do not like the error code.

Index: nsFileChannel.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/file/src/nsFileChannel.cpp,v
retrieving revision 1.115
diff -u -r1.115 nsFileChannel.cpp
--- nsFileChannel.cpp	2001/09/29 08:27:42	1.115
+++ nsFileChannel.cpp	2001/10/05 19:35:18
@@ -476,6 +476,14 @@
                  "wrong thread calling this routine");
 #endif
 
+    PRInt32 aContentLength;
+    GetContentLength(&aContentLength);
+
+    if (!aContentLength && NS_SUCCEEDED(mStatus)) {
+        // we have an empty file and there was not any error
+        mStatus = aStatus = NS_ERROR_FILE_NOT_FOUND;
+    }
+    
     nsresult rv = NS_OK;
     if (mRealListener) {
         rv = mRealListener->OnStopRequest(this, context, aStatus);

Perhaps NS_ERROR_NO_CONTENT would be a better choice...
This is a result of bug 71635 (the dependancy). Its an empty file, thus we must
show an empty page.

The file is there, and we cannot (and must not) claim that it isn't.

Won't error_no_content keep the current page as is? That would be the wrong
behaviour.
So the real issue is that the content type of the blank page is wrong :-)

You don't want a blank text/html page, you want a blank text/plain page...  Is 
this correct?

If this is really the situation, then i believe that you 'might' be able to 
explicitly set the content type of empty files to 'text/plain' and the right 
thing would happen...

Of course, the parser might get in the way and decide to emit an empty HTML 
document anyways... if this happens that that's another bug that needs to be 
fixed :-)

-- rick

That would be a dangerous workaround.  Pretending the file is text/plain would
break scripts that depend on the blank page to have the simple DOM of an empty
HTML file.
Then i'm confused...  If an empty file is *supposed* to be an empty HTML 
document, then where's the bug?

As I understand it, empty files currently display an empty HTML document...

please vend me a clue :-)

-- rick
We must have something which is of the content type of the file, and has no content.

This can't break the DOM - noone is loading an empty file:///foo/bar.txt url and
expecting it to have a valid html dom.

I agree that for about:blank we must have a valid document, but thats not the
issue here.
I'm still confused - it's still too early in the morning :-)

If i understand correctly, the current behavior *is* to display a blank page,
correct?  so, is the issue that the content-type of the 'empty' channel is wrong?

i mean, blank is blank, correct?  visually, there isn't any difference between a
blank text/plain page and a blank text/html page, right?
i can see that if the empty file is 'empty.txt' then you would probably want to
get back 'text/plain' as the content type...

but does it really matter if there is an empty DOM document being displayed
(rather than an empty text/plain document) ?
still clueless (and sleepy)
-- rick

Well, if its a 0 length .zip file, then we want the helper app dialog to appear.
That may be taken care of before we get here though.

The problem is that (from bug 71635), 0 length file=>about:blank, and
about:blank->html, but if we're a text file, then we take the html and display
it as text.
I don't know if you can do ?anything? with a zero byte file, except to say that
it is an empty file... When something like that arrives via HTTP, there might be
some header that gives it context (like being part of a byterange request...) 
ok... so the real issue *is* content-type...  

with a zero-length file (via the file: protocol) we need to perform a mime-type
mapping based on the file extension *even* if the file is empty.  And we need to
fire all of the normal notifications , even if the file is empty...

this way, if the file is of a registered extension, then the correct helper app,
plugin, save as dialog will be presented.

eoes this sound like the desired behavior?

the only issue is what to call empty files that have an unknown extension...  do
we *always* want to treat them as application/octet-stream and bring up a save
as?  i think that this behavior is *really* iritating and useless because i
doubt that anyone ever wants to save an empty file :-)

another option is to treat them as text/plain and display a blank page...  i
think that this is less distuptive to the users browsing experience...

the third option would be to display some 'error page' indicating that the file
is of an unknown type and is empty...

suggestions? comments?

-- rick
Hmm. Yeah, treat it as text/plain iff we don't know about the extention. Its
really an extreme edge case.

Do some things rely on at least one OnDataAvailable being fired?
I don't know about other protocols, but I think a zero byte check would be
something you do before you hand off to any handlers.

I think either bogus HTML (this file is empty) or an error message is needed.

My reasoning for "file:" is this: nobody is going to point to a zero byte file
on purpose. Usually you end up looking at this because it is some truncated file
or failed file creation. 
"<html><body></body><html>" happens when a server redirects using "Location:"
header.  see http://www.myforums.com/
hmm.. my tip build of mozilla has no problem following the redirect for
http://www.myforums.com/

-- rick
Yes the redirect works but Mozilla will briefly display
"<html><body></body><html>".  Buildid 2001102403 on Windows.
This bug was filed specifically about file URL's. 

If my bug is a real depends on 71635, can you file a bug about redirects in the
HTTP componenet?


Filed bug 106558 on the Networking: HTTP component for the redirect problem.
Attachment #55840 - Flags: review+
I'm assuming that there will be a mimetype in a parser context in the normal
case, if so, then the nsAutoString->nsString change will only cost us time
(since we'll have to allocate the string buffer) and not save us any space
(these are trancient objects, so size doesn't really matter that much), so I'd
say don't make that change. Other than that, sr=jst
Okay, this might be totally random b/c I don't understand mime handling very
well, but would some problems be solved if we created a dummy mime/type for
emtpy files? text/empty?
hey johnny...

i agree that the nsAutoString -> nsString change is not a big deal...  the only
reason that i dod it was because:
  - It violates our design pattern of *only* using nsAutoString for stack-based
    allocations.

  - While ParserContexts are 'transitory' objects they do have a significant
    lifetime (ie. the parsing of the document).

Really, the *best* thing to do would be to make the content-type an 'atom' -
since the parser deals with a fixed set of content-types and i believe that all
of these content types are *already* stored as atoms (somewhere...).

But, it's really not a big deal one way or the other...

-- rick

Rick, true, but our design pattern for using nsAutoString only for stack based
objects was kinda bogus :-)
patch checked in (without nsAutoString -> nsString) change
closing out...
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I believe that the fix to this bug causes Mozilla sometimes to freeze, although
I haven't tested it with a nightly yet. The scanner seems to depend on Append()
being called before any other scanner method is used.

And inserting the HTML stuff in the parser seems to be unnecessary even for
empty HTML documents. I have this patch in my tree for months without any
problem (see bug 71635 / bug 57724):

   if(eOnStart==mParserContext->mStreamListenerState) {
-
     //If you're here, then OnDataAvailable() never got called.
-    //Prior to necko, we never dealt with this case, but the problem may have
existed.
-    //What we'll do (for now at least) is construct a blank HTML document.
-    nsAutoString  temp; temp.AssignWithConversion("<html><body></body></html>");
-    mParserContext->mScanner->Append(temp);
-    result=ResumeParse(PR_TRUE,PR_TRUE);
+    mParserContext->mScanner->Append(nsDependentString(&kNullCh, PRUint32(0)));
+    // without this I see occasional crashes
   }

I.e., append an empty string to the scanner's buffer before tokenizing.
This appears to have had the side effect of bug 107945, which crashes Linux
on a redirect with "Location: ..." and a "Content-type: text/plain".
Rick: Refer to bug 108067 that fixes the crash ( null check ) in the scanner.
With the null check you should be good to go [ :-/ ].
Depends on: 108067

        Attachment #55840 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 58801 [details] [diff] [review]
new patch that doesn't hit the bug in the scanner...

r=harishd. This is ok for now. I'll remove this code once bug 108067 gets
fixed.

        Attachment #58801 -
        Flags: review+

    
    

    
  
Comment on attachment 58801 [details] [diff] [review]
new patch that doesn't hit the bug in the scanner...

Heh, this is an awesome workaroud! :-)

sr=jst

        Attachment #58801 -
        Flags: superreview+

    
    

    
  
the 'safer' patch has been checked in.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
i'm reopening this bug (once again) in case we want this fix on the 0.9.4 branch :-)

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
  
No longer depends on: 71635

    
    

    
  
Hi there,

I think this problem belongs here!

If the remote HTTP server has a problem, there are also usually empty HTML
documents returned. This occurs if there are HTTP response headers without HTML
body returned (the server is really badly injured ;).

You should rather show something in the status line or produce a document on the
fly that tells the user that something really ugly occured (present the HTTP
client / server dialogue).



    
    

    
  
There is another bug for that item.

This bug is purely for file:// URL handling.
Summary: file: empty files (0 bytes) display "<html><body></body><html>" → file:// empty files (0 bytes) display "<html><body></body><html>"

    
    

    
  
This appears to be fixed in recent builds.

    
    

    
  
rpotts: did you want to mark this fixed again? nobody did the 0.9.4 keyword
dance, and I've found the following:

WFM:RC1/allplats

    
    

    
  
closing out... 

this patch has been checked into the trunck for a long time (just after 
0.9.4)...  however, the patch never made it to the 0.9.4 branch.

-- rick

Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
VERIFIED:
RC1 looks good. 
Status: RESOLVED → VERIFIED
Whiteboard: notfixed in 094

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: