Interesting report concerning META elements
David Mark
Had a report from Sweden that there was a problem with this test page
in Opera 9.62:-
http://www.cinsoft.net/attributes.html
The problematic code was in one of the baseline DOM property tests:-
el = doc.getElementsByTagName('meta')[2];
assertEquals(el.httpEquiv, 'Cache-Control', "HTTP equivalent");
In short, el was null. Now, of course, there is indeed a third META:-
<meta http-equiv="Cache-Control" content="no-cache">
...put there strictly for the purpose of testing. And it got through
the attribute tests fine, which use the second META:-
<meta http-equiv="Content-Language" content="en-us">
Clearly, in production code, any such logic would have to test that el
is not "falsey" before proceeding. The only cause for a failure here
that I can think of is if that META was stripped by a proxy of some
sort. Unsurprisingly, I was unable to reproduce the problem (even
with that exact version of Opera).
I added a guard against this just so the person reporting the issue
could try again to get all the way through the tests. ISTM that I
should do that for SCRIPT elements, which are known to be removed by
proxies, but META's?
David Mark
>
> I added a guard against this just so the person reporting the issue
> could try again to get all the way through the tests. ISTM that I
> should do that for SCRIPT elements, which are known to be removed by
> proxies, but META's?
Thinking about that again, there is already a check that would short-
circuit the tests if the one SCRIPT element were missing (it's the one
with the attr and prop functions after all).
David Mark
> Clearly, in production code, any such logic would have to test that el
> is not "falsey" before proceeding. The only cause for a failure here
> that I can think of is if that META was stripped by a proxy of some
> sort.
That was it. Firewall (or whatever) stripped the cache-control META.
Probably not the best choice for a test META. :)