HTML Standard Tracker

Filter

File a bug

SVNBugCommentTime (UTC)
2470Remove the WWW-Authenticate 'HTML' scheme and replace it with requirements on browsers to ignore unknown schemes.2008-11-27 20:37
@@ -33040,66 +33040,20 @@ interface <dfn>HTMLOptionElement</dfn> : <span>HTMLElement</span> {
    title="">event name</var> be <code
    title="event-formchange">formchange</code>.</li>
 
    <li><p>For each element in <var title="">controls</var>, in
    <span>tree order</span>, <span>fire a simple event</span> named
    <var title="">event name</var> at the element.</p></li>
 
   </ol>
 
 
-  <h4>Login forms</h4>
-
-  <p>A common use for forms is user authentication. To indicate that
-  an HTTP <span>URL</span> requires authentication through such a form
-  before use, the HTTP 401 response code with a <code
-  title="">WWW-Authenticate</code> challenge "<code
-  title="">HTML</code>" may be used.</p>
-
-  <p>For this authentication scheme, the framework defined in RFC2617
-  is used as follows. <a href="#refsRFC2617">[RFC2617]</a></p>
-
-  <pre><dfn title="bnf-formauth-challenge">challenge</dfn> = "<code title="">HTML</code>" [ <span title="bnf-formauth-form">form</span> ]
-<dfn title="bnf-formauth-form">form</dfn>      = "<code title="">form</code>" "<code title="">=</code>" <span title="bnf-formauth-form-name">form-name</span>
-<dfn title="bnf-formauth-form-name">form-name</dfn> = quoted-string</pre>
-
-  <p>The <span title="bnf-formauth-form">form</span> parameter, if
-  present, indicates that the first <code>form</code> element in the
-  entity body whose <span title="attr-form-name">name</span> is the
-  specified string, in <span>tree order</span>, if any, is the login
-  form. If the parameter is omitted, then the first <code>form</code>
-  element in the entity body, in <span>tree order</span>, if any, is
-  the login form.</p>
-
-  <p>There is no <code title="">credentials</code> production for this
-  scheme because the login information is to be sent as a normal form
-  submission and not using the <code title="">Authorization</code>
-  HTTP header.</p>
-
-  <p>This authentication scheme must only be used for entities whose
-  bodies contain HTML or XML with at least one <code>form</code>
-  element.</p>
-
-  <p class="note">Pages that include a login form but are not
-  protected by the login form (and for which a 401 response would
-  therefore be inappropriate) can have an "<code title="">HTML</code>"
-  challenge included in a <code title="">WWW-Authenticate</code>
-  header even though the response code is not 401. This allows user
-  agents to identify login forms on pages even when the user might not
-  want to log in.</p>
-
-  <p class="note">The lack of a <code
-  title="bnf-formauth-realm">realm</code> parameter in the challenge
-  is an intentional violation of RFC2617 (it isn't clear how the realm
-  concept would apply in this context).</p>
-
-
 
   <h3 id="interactive-elements">Interactive elements</h3>
 
   <h4>The <dfn><code>details</code></dfn> element</h4>
 
   <dl class="element">
    <dt>Categories</dt>
    <dd><span>Flow content</span>.</dd>
    <dd><span>Interactive content</span>.</dd>
    <dt>Contexts in which this element may be used:</dt>
@@ -41925,20 +41879,35 @@ user reload must be equivalent to .reload()
     following:</p>
     <ul class="brief">
      <li>HTTP status codes (e.g. 204 No Content or 205 Reset Content)</li>
      <li>HTTP Content-Disposition headers</li>
      <li>Network errors</li>
     </ul>
    </div>
    
     <!-- XXX should we define 205 processing here? e.g. reset all forms? -->
 
+    <p>HTTP 401 responses that do not include a challenge recognised
+    by the user agent must be processed as if they had no challenge,
+    e.g. rendering the entity body as if the response had been 200
+    OK.</p>
+
+    <p>User agents may show the entity body of an HTTP 401 response
+    even when the response do include a recognised challenge, with the
+    option to login being included in a non-modal fashion, to enable
+    the information provided by the server to be used by the user
+    before authenticating. Similarly, user agents should allow the
+    user to authenticate (in a non-modal fashion) against
+    authentication challenges included in other responses such as HTTP
+    200 OK responses, effectively allowing resources to present HTTP
+    login forms without requiring their use.</p>
+
    </li>
 
    <li><p>Let <var title="">type</var> be <span title="Content-Type
    sniffing">the sniffed type of the resource</span>.</p></li>
 
    <li><p>If the user agent has been configured to process resources
    of the given <var title="">type</var> using some mechanism other
    than rendering the content in a <span>browsing context</span>, then
    skip this step. Otherwise, if the <var title="">type</var> is one
    of the following types, jump to the appropriate entry in the

|