- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Sun, 5 Nov 2006 13:26:03 -0800
- To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Robert Sayre <sayrer@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Nov 4, 2006, at 12:41 PM, William A. Rowe, Jr. wrote: > > Lisa Dusseault wrote: >> >> So I guess a decision that CLIENTS MUST support Basic and Digest in a >> new HTTP RFC, might be signalled by a minor version bump.[...] > >> But a decision that SERVERS MUST support Basic and Digest -- well >> that >> doesn't need a version bump at all to work. We already have a way >> for >> servers to advertise support insofar as that's necessary for those >> algorithms. > > This doesn't parse - it would immediately break a massive number of > web > applications, much as microsoft recently did in the IE client > 'security' > patches through their re-POST of failed POST requests sans-request- > body. > Requirements even on the server side can't realistically be altered > within the confines of HTTP/1.0 /1.1. > > The only answer is to remove Basic for HTTP/1.2 or /2.0 in the future > revision of the spec as a fundamentally broken mechanism, much as the > HTTP/1.1 spec introduced manditory Host headers to force all browsers > over to mass vhosting by-name. I didn't mean that servers must USE Basic and Digest to replace form- based security -- you're right, that would break a bunch of Web applications. IETF specs tend to make requirements of implementations and less often make requirements of deployments or administrators or sites. An implementation may SUPPORT Basic and Digest as required, and also support form-based auth, and continue to use form-based auth to make their WebUIs run. Lisa
Received on Sunday, 5 November 2006 21:26:23 UTC