87537 - Refresh: doesn't work with multipart/mixed documents

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P5)

Description

[Christopher Blizzard (:blizzard)]

If you use the Refresh http header with a multipart/mixed document it never
refreshes.  You can see an example of this here:

http://www.ideasuite.com/~blizzard/nph-referrer-header.cgi

Some crack smoking fiends even put the Refresh in the HTML part of the document:

http://www.ideasuite.com/~blizzard/nph-referrer-doc.cgi

Neither of these work and they both work in Netscape 4.x and in IE.

The problem with the first is that there's no way for the code that queries the
refresh information on the channel to get that information from the multipart
channel since that information is only available from an HTTP channel.

Since the nsPartChannel in the multipart converter has access to the HTTP
channel it's possible to get this information from there.  The question is, how
do we get that information from the docshell?  I considered adding the HTTP
interface to the nsPartChannel and just pushing requests down the line but I
suspect that there are times when using a multipart document the caller of it
won't actually be a http channel.

So, what do do?  Any advice?

Comment 1

[neeti]

darin

Comment 2

[Darin Fisher]

-> dougt

Comment 3

[Doug Turner (:dougt)]

dup.

*** This bug has been marked as a duplicate of 70398 ***

Comment 4

[Christopher Blizzard (:blizzard)]

This isn't a dup.  The test case in the other bug just keeps resetting the
content with a held open connection.  This bug is about using actual Refresh:
headers that should cause a complete reload.

Comment 5

[Doug Turner (:dougt)]

rick, can you advise.  

Could we allow the part channel to have an accessor back to the multipart 
channel?  

Comment 6

[rpotts (gone)]

I'm moving this milestone -> 1.0 since this will not get fixed on the branch...

Comment 7

[rpotts (gone)]

I talked this issue over with jud for quite a while...  the decision we finally
came to was that each nsPartChannel should also implement nsIHTTPChannel.

The reasoning was that because each part intrinsically looks like a HTTP
response (complete with headers) it should implement the same interface...

It would be nice if the header accessor methods were not part of nsIHTTPChannel,
but some other interface such as nsIHTTPHeaders...  But, since its not that way,
they should just implement all of nsIHTTPChannel...

-- rick

Comment 8

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 9

[Olivier Cahagne]

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

Comment 10

[benc]

-> defaults

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Is this still relevant in today's web? I don't think we've done anything to fix it

Comment 13

[Valentin Gosu [:valentin] (he/him)]

I don't think it's important anymore. Both the refresh header and multipart are niche features.

From what I understand, the problem here was that the document would get the header from the channel here, then call SetupURIRefreshFromHeader. However, since nsPartChannel doesn't implement nsIHttpChannel, it's not a full HTTP channel implementation, so it never gets the refresh header in the multipart response.

I am a bit surprised comment 0 says that meta refresh doesn't work either, but that was 23 years ago 🙂

In any case, I'm hoping bug 1276918 will land at some point. Until then we can close this as WONTFIX - though the resolution could also be INACTIVE instead.