Closed Bug 86133 Opened 23 years ago Closed 23 years ago

Conn+DNS: no "could not be found" dialog for DNS errors

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: buggage1999, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: critical for 0.9.2, r=gagan, sr=waterson, a=blizzard for 0.9.2 PDT+, checked in on the trunk)

Attachments

(3 files)

Fix to http
(deleted), patch
Details | Diff | Splinter Review
uri loader change
(deleted), patch
Details | Diff | Splinter Review
fixes the problem
(deleted), patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.1+) Gecko/20010615
BuildID:    2001061504

2001061504

When entering or trying to go to a non-existant url like the one above, there is
no message 'this website can't be found'.  It simply stops looking and gives no
info.

Reproducible: Always
Steps to Reproduce:
1. Go to a bad url
2.
3.

Actual Results:  No message

Expected Results:  Should get the 'website cannot be located' message
Indeed.  I saw this yesterday and didn't realize what was happening.
confirmed on Win2K, WinXP, same build.  worked fine a few days ago.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 86140 has been marked as a duplicate of this bug. ***
CC:Gordon
Gordon this seem to be a regression of your DNS landing
Keywords: regression
*** Bug 86294 has been marked as a duplicate of this bug. ***
Depends on: 86320
changing OS to All; this looks to be a bigger problem than first thought
No longer depends on: 86320
Keywords: mozilla0.9.2, nsbeta2
OS: Windows ME → All
Depends on: 86320
Blocks: 80493
->gordon, this seems dns related
Assignee: neeti → gordon
In my tests before I landed my changes, I was still get the dialog reporting the
unknown host, so at first glance I don't think this is a problem with the DNS
code.  It is still reporting the same errors it always was.  I'll investigate
further.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2
We are talking about the fix in bug 85802 or something even before that, right?
changed summary, cleaned dupes.
Summary: bad url's dont tell you they cannot be found → DNS: no "could not be found" dialog for DNS errors
By the way, the DNS service knows nothing about this dialog.  It's displayed by
UI code higher up the chain.
*** Bug 86485 has been marked as a duplicate of this bug. ***
+mostfreq to prevent new bugs and catch dupes.
Keywords: mostfreq
*** Bug 86703 has been marked as a duplicate of this bug. ***
*** Bug 86793 has been marked as a duplicate of this bug. ***
Gordon, can we make this P1?
*** Bug 86963 has been marked as a duplicate of this bug. ***
Whiteboard: critical for 0.9.2
I've noticed that the dialog that you would normally get when the connection was
refused to a server isn't being thrown either.  It's not just DNS.
Summary: DNS: no "could not be found" dialog for DNS errors → Conn+DNS: no "could not be found" dialog for DNS errors
gordon, can we get an update on where you are with this one?
Whiteboard: critical for 0.9.2 → critical for 0.9.2, need status update and ETA
I am not looking at this bug.  Gagan said he would look into it.  It almost
certainly doesn't have anything to do with the DNS service.
bug 87293 is a possible dup

jake
taking over for investigation...
Assignee: gordon → gagan
Status: ASSIGNED → NEW
meow
Keywords: 4xp, nsCatFood
Hardware: PC → All
Not sure if this is related, but if you type a url like:

foo:8080/

or even:

localhost:8080/

you get the following javascript error:

Error: uncaught exception: [Exception... "Component returned failure code: 
0x804b0012 [nsIIOService.newURI]"  nsresult: "0x804b0012 (<unknown>)"  
location: "JS frame :: chrome://navigator/content/sessionHistoryUI.js :: 
addToUrlbarHistory :: line 141"  data: no]

and then, of course you get no message saying "location not found", or whatever

However, if you put http:// in front of it: http://foo:8080
Or just do: foo

you don't get the javascript error, but, of course still experience the main 
problem of this bug.

if you use: http://localhost:8080/

everything works just fine (as long as you have a server there, which I do).

Jake
sorry, the behavior I just mentioned is covered by bug 87250

Jake
*** Bug 87591 has been marked as a duplicate of this bug. ***
*** Bug 87595 has been marked as a duplicate of this bug. ***
This is a 0.9.2 bug.  What's going on with this bug?
Whiteboard: critical for 0.9.2, need status update and ETA → critical for 0.9.2, need status update and ETA; no patch
The problem is that http fires the OnStopRequest before it knows about any 
content type.  When the URILoader asks this http channel about the content type, 
the function returns an error now.  I have modified the URILoader to know about 
this error, and the problem goes away.  However, I think that the real bug is 
that http returns an error in the first place.  It should just return 
"UNKNOWN_CONTENT_TYPE" if the |mResponseHead| is not present.
Whiteboard: critical for 0.9.2, need status update and ETA; no patch → critical for 0.9.2, need status update and ETA
Attached patch Fix to http (deleted) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        uri loader change (deleted)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Either of the two above fixes will work.  I tend to feel that the first one is 
more correct, but Darin does have a case if he disagrees.

Both of the patches will assert because http still returns an error if the 
content type is set before the mResponseHead is present.

Darin, gagan, lets pick between these two patches, give one of them an r=, and 
lets get this approved to be checked in.

    
    

    
  
Just as I found the same thing (though the hard way) Mr. Dougt submits a patch! 
:-) r=gagan on the second patch. I wouldn't approve of the HTTP patch since at 
the very least it should fail with a different reason (not unknown_content_type)
Assignee: gagan → dougt

    
    

    
  
in the error case, HTTP will _never_ know a content-type, because there is no 
response from the server (a connection couldn't be established)... thus no
mResponseHead.

without a response from the server (mResponseHead==NULL), GetContentType()
returns NS_ERROR_NOT_AVAILABLE.  i think this is reasonable and correct
behavior... returning UNKNOWN_CONTENT_TYPE in this case is IMO be both
misleading and unnecessary.

also, your first patch can result in an infinite loop (i forget the bug
number).  this is because SetContentType() will fail (mResponseHead==NULL),
which can lead to an infinite loop between the uriloader and the unknown
content converter.  i suspect your second patch will also have this problem.

why do we need to fake the content type to report the "host not found" error?

also, mozilla0.9.1 doesn't have this problem, and the code in
nsHttpChannel::GetContentType has not changed since before 0.9.1, so how could
it be the cause of the problem?

    
    

    
  
Found the *real* problem.  A cancel is called on nsHttpTransation with the error 
code NS_ERROR_NOT_AVAILABLE.  This overwrites the previous mStatus which was 
host_not_found.  NS_ERROR_NOT_AVAILABLE is not recognized by the webshell as any 
status that it should put up an dialog for....

Over to darin.  Darin, maybe we should only set mStatus if it is not an error... 
 That should fix this problem.
Assignee: dougt → darin

    
    

    
  
good job tracking this down :-)

we're likely returning NS_ERROR_NOT_AVAILABLE from OnStartRequest, which causes
the request (in this case the HTTP transaction) to be canceled.  we could simply
patch this as you suggest (and maybe that is the best thing to do in order to
prevent this sort of regression in the future), but i wonder if this isn't
indicative of something more being incorrect.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fixes the problem (deleted)
        — 
          — Splinter Review
      

    


  

    
    

    
  
i thought about fixing nsRequestObserverProxy to not call Cancel if
NS_FAILED(request->Status), but that may incorrect, since some channel
implementations may depend on the Cancel to drive OnStopRequest... not 
that i can think of any such channels but it doesn't seem that far fetched.

at any rate, this problem was easily fixed in nsHttpTransaction::Cancel.

    
    

    
  
r=gagan on last patch

    
  
Keywords: patch
Whiteboard: critical for 0.9.2,  need status update and ETA → critical for 0.9.2, r=gagan, sr=?, a=?

    
    

    
  
sr=waterson

    
  
Whiteboard: critical for 0.9.2, r=gagan, sr=?, a=? → critical for 0.9.2, r=gagan, sr=waterson

    
    

    
  
fix checked into the trunk... hoping to land this on the 0.9.2 branch as well.
Status: NEW → ASSIGNED

    
    

    
  
Lets land this on the branch the fix is small and safe.
Keywords: nsBranch
Whiteboard: critical for 0.9.2, r=gagan, sr=waterson → critical for 0.9.2, r=gagan, sr=waterson, PDT+

    
  
Whiteboard: critical for 0.9.2, r=gagan, sr=waterson, PDT+ → critical for 0.9.2, r=gagan, sr=waterson, PDT+, checked in on the trunk

    
    

    
  
just replacing nsbeta2->nsbeta1 since nobody seems to use nsbeta2 anymore
Keywords: nsbeta2 → nsbeta1

    
    

    
  
a=blizzard on behalf of drivers for 0.9.2.

If you guys don't have a branch build I can check it in for you to get this done
faster.  Let me know.
Whiteboard: critical for 0.9.2, r=gagan, sr=waterson, PDT+, checked in on the trunk → critical for 0.9.2, r=gagan, sr=waterson, a=blizzard for 0.9.2 PDT+, checked in on the trunk

    
    

    
  
fix checked in to the 0.9.2 branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
VERIFIED:
All plats, 07-17-03-0.9.2 commercial final candidate build.

DNS failure and connection failures do error.

+vtrunk - I think this still needs trunk verification b/c I also tested this on
NS 6.1b1, which was still off the branch...
Status: RESOLVED → VERIFIED
Keywords: vtrunk

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: