20838 - Conn: Unreachable server should cause cached data to be displayed

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement, P3)

Description

[Scott Furman]

In prior versions of Navigator, the cached version of a page was shown (with a
warning dialog) if the origin server could not be contacted.

Comment 1

[Warren Harris]

Mass move of all bugs without target milestones to M13.

Comment 2

[leger]

Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.

Comment 3

[Warren Harris]

Assigning fur's cache bugs to Gordon. He can split them up with davidm.

Comment 4

[Warren Harris]

Seems non-essential for beta. Moving to M15.

Comment 5

[gordon]

Assigning to ruslan per warren's request.

Comment 6

[Warren Harris]

Moving to M17 which is now considered part of beta2.

Comment 7

[ruslan]

I added some code (not enabled yet) which will return the cached response in 
cases when the connection can't be established with the Success serverity but 
with the original error code. The docshell needs to check for the error code and 
if it's there - pop-up the dialog box complaining about it.

Comment 8

[travis]

Um, details on where this error is returned from?

Comment 9

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.  Assigning to valeski 
temporarily.

Comment 10

[Judson Valeski]

ruslan, is your code in? what code do we look for?

Comment 11

[ruslan]

It's in and it can be enabled, but the docshell needs to display smth. Necko 
will just return cached copy.

Comment 12

[Judson Valeski]

ruslan, how do we know when it's cached? check some status code on the channel?

Comment 13

[Judson Valeski]

-> gagan until we get a better idea of what to look for.

Comment 14

[Péter Bajusz]

Clearing very old milestone (M17) in hope of reevaluation.

Comment 15

[Gagan]

should be looked at after the new cache lands. 
->neeti

Comment 16

[gordon]

Darin, any suggestions on what to do with this bug?  Do you know anything about 
what Ruslan put in place?

Comment 17

[Gagan]

The correct/clean way IMHO is that we should intercept the errors propogated 
from the transport. currently we don't!-- we just let it send the error message 
directly to the progress listener handed in to the channel. So essentially we 
need a progress listener (in the channel) that we can hand over to the socket 
transport. once we get the notification of server not reached, we should turn 
around pop up the alert box and send data from the cache. 

Comment 18

[Darin Fisher]

gagan: i agree

Comment 19

[gordon]

...but hasn't HTTP already truncated/doomed the old cache entry?  Maybe not, if 
it was simply trying to validate the entry.  Sounds like this is an HTTP issue, 
more than a cache issue.

Comment 20

[Gagan]

moving to 0.9.2

Comment 21

[neeti]

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

Comment 22

[benc]

qa to me.

Comment 23

[R.K.Aa.]

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

Comment 24

[Jesse Ruderman]

See also bug 28586, Should use placeholder error page, not dialog, for 
inaccessible pages.

Comment 25

[Andrew Hagen]

This would be a nice improvement, and relatively simple to implement. Nominating
for Mozilla 1.0 and nsbeta1.

Comment 26

[Gagan]

per adt, not critical for nsbeta1. hence minus.

Comment 27

[benc]

+ conn - working on more detailed offline/online testcases. 

Comment 28

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 29

[Patrick McManus [:mcmanus]]

we do some different things in offline mode - which seems like the right plan for now