http://www.algo-prog.info/ocmc/ contains <meta http-equiv="refresh" content="0;web/" /> For refresh, we assume there will be an '=' from "URL=". Since there isn't one, we refresh the same URL over and over and over... We could refuse to follow a zero-delay refresh without a new URL, but I seem to recall back in the never-follow days that sometimes a page _wanted_ to be immediately refreshed once, after which it would provide the contents (I always wondered why). So perhaps the nav redirection stuff should use bw->redirect_level.
On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote:
http://www.algo-prog.info/ocmc/ contains <meta http-equiv="refresh" content="0;web/" />
For refresh, we assume there will be an '=' from "URL=".
Unfortunately there's no standard for the content string in a META refresh. The example by W3C uses "URL=" so it looks OK to expect it.
Since there isn't one, we refresh the same URL over and over and over...
We could refuse to follow a zero-delay refresh without a new URL, but I seem to recall back in the never-follow days that sometimes a page _wanted_ to be immediately refreshed once, after which it would provide the contents (I always wondered why).
So perhaps the nav redirection stuff should use bw->redirect_level.
This looks like a good idea. If you want to make a patch go ahead, I'll look at the expect url issue with zero-delay refresh now. -- Cheers Jorge.-
Jorge wrote:
On Thu, Apr 22, 2010 at 05:53:00AM +0000, corvid wrote:
http://www.algo-prog.info/ocmc/ contains <meta http-equiv="refresh" content="0;web/" />
For refresh, we assume there will be an '=' from "URL=".
Unfortunately there's no standard for the content string in a META refresh. The example by W3C uses "URL=" so it looks OK to expect it.
I was tempted to complain in my previous mail about how it was underspecified :) Some sufficiently old html specs didn't show the URL=, incidentally http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.4.4
Jorge wrote:
So perhaps the nav redirection stuff should use bw->redirect_level.
This looks like a good idea. If you want to make a patch go ahead, I'll look at the expect url issue with zero-delay refresh now.
I see that, in Cache_process_queue(), redirect_level is zeroed if CA_Redirect isn't set. I wonder whether, since this is http-equiv, it should reach into cache in a way that's similar to Content-Type and let us rip out the nav redirection code.
On Fri, Apr 23, 2010 at 01:19:28AM +0000, corvid wrote:
Jorge wrote:
So perhaps the nav redirection stuff should use bw->redirect_level.
This looks like a good idea. If you want to make a patch go ahead, I'll look at the expect url issue with zero-delay refresh now.
I see that, in Cache_process_queue(), redirect_level is zeroed if CA_Redirect isn't set. I wonder whether, since this is http-equiv, it should reach into cache in a way that's similar to Content-Type and let us rip out the nav redirection code.
This may be a sleeping dragon. It could look cleaner if handled in cache, but there's a need to sync the redirecting-URL not to end in the history stack, while at the same time letting the resource finish loading and to assert repush works OK (part of this is achieved by using a timeout in nav). Maybe it can be done easily, I don't know yet. Although I remember very well that "charset" given by HTML's META was a royal PITA to handle! (chicken/egg problem). ATM we're handling zero-delay redirection for root URLs only. I see little use for generalizing it to child resources. I see clear gain in the case of HTTP redirection. My point is: it could take a significative effort that would be better spent on something more urgent/strategic for the project. -- Cheers Jorge.-
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org