While using dillo to check some pages for AnyBrowser-friendliness, I've encountered the warning inserted whenever a <meta http-equiv="refresh" ...> tag is used. I interpreted this as meaning that the HTML I'd written was in some way wrong, and I should find another way to achieve the same effect. The warning says: This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it. I checked that part of the HTML spec to see exactly what it said, and whether it suggested any better alternatives. However, all that section has to say about the use of "refresh" is: ( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 ) Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should not use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects. My understanding of that paragraph is that it's only recommending against redirection, in which the refresh tag specifies that a different page should be loaded after the timeout. It might additionally mean that it's only discouraged for "instant" (ie. delay=0) redirection. OTOH, refreshing the same page (which is what I'm trying to do with the page that I'm writing) should be OK. In this case, shouldn't dillo only complain if the "content" part of the tag contains a "URL=" (even if it won't handle the refresh without the aid of the meta-refresh patch)? I can write the necessary trivial patch to insert such a check if people agree that it's The Right Thing, but I thought I'd better check that I've interpreted the spec properly (and am reading the right bit of it) before I do so. Glyn
Glyn Kennington wrote:
While using dillo to check some pages for AnyBrowser-friendliness, I've encountered the warning inserted whenever a <meta http-equiv="refresh" ...> tag is used. I interpreted this as meaning that the HTML I'd written was in some way wrong, and I should find another way to achieve the same effect.
The warning says:
This page uses the NON-STANDARD meta refresh tag. The HTML 4.01 SPEC\n" " (sec 7.4.4) recommends explicitly to avoid it.
I checked that part of the HTML spec to see exactly what it said, and whether it suggested any better alternatives. However, all that section has to say about the use of "refresh" is:
( http://www.w3.org/TR/html401/struct/global.html#h-7.4.4 )
Note. Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. Authors should not use this technique to forward users to different pages, as this makes the page inaccessible to some users. Instead, automatic page forwarding should be done using server-side redirects.
My understanding of that paragraph is that it's only recommending against redirection, in which the refresh tag specifies that a different page should be loaded after the timeout. It might additionally mean that it's only discouraged for "instant" (ie. delay=0) redirection.
OTOH, refreshing the same page (which is what I'm trying to do with the page that I'm writing) should be OK. In this case, shouldn't dillo only complain if the "content" part of the tag contains a "URL=" (even if it won't handle the refresh without the aid of the meta-refresh patch)?
I can write the necessary trivial patch to insert such a check if people agree that it's The Right Thing, but I thought I'd better check that I've interpreted the spec properly (and am reading the right bit of it) before I do so.
May be you can modify my patch, as far I know it works with 0.8.5 http://www.roberto.foglietta.name/pub/dillo/ It able to refresh AND redirect, but only if -r option is specified in command line. May be you can modify it to refresh ALWAYS and use -r option ONLY for redirect when time is more than the specified offset -r <seconds> Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253
Roberto A. Foglietta wrote:
http://www.roberto.foglietta.name/pub/dillo/
It able to refresh AND redirect, but only if -r option is specified in command line. May be you can modify it to refresh ALWAYS and use -r option ONLY for redirect when time is more than the specified offset
-r <seconds>
The more I think about how I'd go about hacking this functionality in, the more questions it brings up... As well as a time boundary, I think it would probably be best to include another option to specify which refreshes to honour. At the moment it's a simple choice between 1 (default): no refresh 2 (with -r): all refreshes permitted Rather than changing the first to be "refresh only, no redirect", could I suggest some kind of choice between the following three? 1: no refresh 2: refreshes allowed, redirects not 3: refreshes + redirects permitted And then we get into the murky area of limiting the times for these. Could/should it be a different value for refreshes and for redirects? What to do if the page requests a shorter timeout than allowed: ignore it altogether, or handle after the minimum timeout has elapsed? Is that too many command-line options? Would an entry (or several) in dillorc be more suitable? Glyn
Glyn Kennington ha scritto:
Roberto A. Foglietta wrote:
http://www.roberto.foglietta.name/pub/dillo/
It able to refresh AND redirect, but only if -r option is specified in command line. May be you can modify it to refresh ALWAYS and use -r option ONLY for redirect when time is more than the specified offset
-r <seconds>
The more I think about how I'd go about hacking this functionality in, the more questions it brings up...
As well as a time boundary, I think it would probably be best to include another option to specify which refreshes to honour. At the moment it's a simple choice between
1 (default): no refresh 2 (with -r): all refreshes permitted
Rather than changing the first to be "refresh only, no redirect", could I suggest some kind of choice between the following three?
1: no refresh 2: refreshes allowed, redirects not 3: refreshes + redirects permitted
And then we get into the murky area of limiting the times for these. Could/should it be a different value for refreshes and for redirects? What to do if the page requests a shorter timeout than allowed: ignore it altogether, or handle after the minimum timeout has elapsed?
Is that too many command-line options? Would an entry (or several) in dillorc be more suitable?
that sounds good: -r only refresh -rr redirect too but I think that dillo could not complain about refresh because they are HTML-standard compliant and it is the reason because meta-refresh was been invented. So if we would stay on the standards we have to accept it even if we don't like it. The reason because I decided not to include the option in dillorc is beacuse -r -rr could be an alias which the user could setup in his/her shellrc while dillorc could be modified acrivating the option by distribution without knowledge of end-users. In this last case safe behaviure of dillo would be overloaded out of our/end-user control. Warning on refresh are very boring and fails completely in automated systems like embedded while warning on redirect could be much more acceptable for end users. So I think my patch was not so much usefull if dillo was HTML-stadard compliant but because my refresh needs we could discover (and sombody else) fix a very evil memory leak bug in pthread library. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253
Roberto A. Foglietta wrote:
Glyn Kennington ha scritto:
Rather than changing the first to be "refresh only, no redirect", could I suggest some kind of choice between the following three?
1: no refresh 2: refreshes allowed, redirects not 3: refreshes + redirects permitted
[...]
that sounds good:
-r only refresh -rr redirect too
I'll get to work on that. I'm not sure if "-rr" breaks certain coding standards, it being neither a "short" (only one character) nor "long" (starting with two dashes) option, but that's not especially important (to me) right now.
but I think that dillo could not complain about refresh because they are HTML-standard compliant and it is the reason because meta-refresh was been invented. So if we would stay on the standards we have to accept it even if we don't like it.
It's dubious whether it's standard HTML, actually. The spec says that the "http-equiv" must be valid HTTP, effectively passing the buck to the HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, I'm still uncertain about all this... Glyn
Glyn Kennington wrote:
Roberto A. Foglietta wrote:
-r only refresh -rr redirect too
I'll get to work on that.
OK, here's one very poorly tested diff. Apply it after applying the main "refresh" patch. It should work against current CVS, nothing else tried. It's a bit of a hack, but no more so than your own patch ;-) I'll leave the timelimit part until I've thought about it a bit more. Glyn
Glyn Kennington schrieb:
-r only refresh -rr redirect too
I'll get to work on that. I'm not sure if "-rr" breaks certain coding standards, it being neither a "short" (only one character) nor "long" (starting with two dashes) option, but that's not especially important (to me) right now.
How about "-R" for "redirect too"? Also, dillo's error message when parsing the command line is not very helpful: |$ dillo -help |Error in command line options. Maybe at some time I'll look into making this more specific.
but I think that dillo could not complain about refresh because they are HTML-standard compliant and it is the reason because meta-refresh was been invented. So if we would stay on the standards we have to accept it even if we don't like it.
It's dubious whether it's standard HTML, actually. The spec says that the "http-equiv" must be valid HTTP, effectively passing the buck to the HTTP spec. And as the HTTP spec is in a fairly unreadable RFC format, I'm still uncertain about all this...
Actually, as I read it, the META-refresh is not an HTTP header at all. At least it does not occur anywhere in the HTTP spec. The HTML 4.0 spec says: Some user agents support the use of META to refresh the current page after a specified number of seconds, with the option of replacing it by a different URI. <META http-equiv="refresh" content="3,http://www.acme.com/intro.html"> The content is a number specifying the delay in seconds, followed by the URI to load when the time is up. [...] However, since some user agents do not support this mechanism, [...] Regards Alexander -- PGP key available Port Payé / Entgelt bezahlt / Postage Paid: http://www.hashcash.org/
Glyn Kennington wrote:
I can write the necessary trivial patch to insert such a check if people agree that it's The Right Thing, but I thought I'd better check that I've interpreted the spec properly (and am reading the right bit of it) before I do so.
Well, as nobody's tried to put me right on this, here's some patches (taken against current CVS, and they can be applied to 0.8.5): First, the "safe" patch. This removes the reference to the spec's "explicit recommendation" if it's a simple refresh with no redirection. A warning is still generated. Second, the "controversial" patch ;-). This removes the warning altogether when the refresh doesn't involve redirection. Glyn
participants (3)
-
Alexander Becher -
Glyn Kennington -
Roberto A. Foglietta