Sylvain Hellegouarch wrote: > Ian, > > > Why disallowing the application to set the WWW-Authenticate header? If a > middleware is present it will be overwritten anyway. If no middleware is > there then at least you won't break the first MUST in section 10.4.2 of > RFC 2616.
I suppose there's no problem with it; though of course if you response with "WWW-Authenticate: Basic" and then don't have enough information to handle the response, you don't be doing anything useful. "WWW-Authenticate: x-internal-wsgi" would be... well, explicit at least ;) > What happens if part of my application is to be protected by OpenID, > another by Digest and a third one by a in-house auth scheme? How does your > spec. deal with this? You'd have to lay out and configure your middleware appropriately. Though I can imagine a problem where you have Digest in a specific area with OpenID everywhere else; the OpenID would catch the Digest response and rewrite it. I guess there might be some purpose to the WWW-Authenticate header there too. You could say that a 401 response with a x-internal-wsgi authentication type (or a missing WWW-Authenticate header) should be handled by middleware; other responses should be ignored. This is also useful for WebDAV areas, which probably live in a subdirectory somewhere and have more limited client authentication support. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
