Redirection Chains

Johnath, you note:

>Note that this applies whether or not the resource in which the
>non-interactive chain of
>
>    * redirections terminates is TLS protected in any manner. In
>    particular, even if the retrieval of the final resource in the
>    chain of redirections is strongly TLS protected, clients MUST
>    signal an error. Also note that this section is not limited to
>    HTTP level redirection mechanisms; it also covers redirections
>    that are caused by scripting or HTML constructs. 
>   
>This section is confusing since it suggests that we are signalling
>an error, not a warning as mentioned above. It's also not clear how
>to interpret this text in light of things like image transfers
>which, if they occurred over unprotected connections would be cause
>for mixed mode treatment, but not warnings or errors. I can't
>declare conformance here at the moment, given these confusions.

http://www.w3.org/2006/WSC/wiki/Firefox_3.0_Conformance_with_June_LC

The "signal an error" language is old, and preceded the introduction
of the different error signalling levels, if I recall correctly.

I'd also note that, in the framing text, we say "signal an error of
class warning or above", so I'm not sure how confusing "signal an
error" really is here -- even though your confusion about it
certainly is a warning sign.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 11 June 2008 09:24:20 UTC