Closed Bug 102737 Opened 23 years ago Closed 23 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 → 23 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: