I think it is well established that HTTP Authentication needs a major kick in the ass and OpenID and OAuth may get us most of the way there. However, until I see RFC#’s attached to both I’m hardly going to consider them to be complete. I propose the creation of an IETF WG on Identity and Authentication. The WG would be chartered to produce two RFC’s covering each of the two areas. OpenID and OAuth could be used to seed the WG effort.
dive into mark » There are no exceptions to Postel’s Law
Another suggestion was that we do away with the Atom autodiscovery <link> element and just use an HTTP header, because parsing HTML is perceived as being hard and parsing HTTP headers is perceived as being simple. This does not work for Bob either, because he has no way to set arbitrary HTTP headers. It also ignores the fact that the HTML specification explicitly states that all HTTP headers can be replicated at the document level with the <meta http-equiv="..."> element. So instead of requiring clients to parse HTML, we should just require them to parse HTTP headers… and HTML.
HTTP Basic Authentication, A Tale of AtomPub, WordPress, PHP, Apache, CGI and SSL/TLS - Joseph Scott's Blog
Hopefully everyone takes away two things from this. One, you can’t depend on HTTP basic authentication working. Two, if you aren’t using SSL/TLS then your traffic isn’t secure.
PUT and DELETE dropped on the floor
I mentioned previously that the AtomPub server in my WordPress installation wasn't successfully deleting entries. More specifically, I get a 403 Forbidden when trying to PUT or DELETE posts or media files. I posted to the wp-testers mailing list and Joseph Scott passed the question along to Sam Ruby, Tim Bray, Elias Torres, and Pete Lacey, and I basically eavesdropped on their conversation.
Turns out that the problem is likely to be a firewall rejecting PUTs and DELETEs. This started a discussion of how WordPress should workaround the problem. Some options are URL munging, custom headers, or message in a message. All horrible for various and obvious reasons, and none going to make it into 2.3. Sam cautioned, and suggested revisiting PacePutDelete, a method proposed by Joe Gregorio on the Atom lists to overcome a lack of PUT and DELETE support on clients, which led me off on a fascinating journey through the Atom mailing list archives.
I'm not sure how big the problem really is now. It may take more time and effort to come up with a "fix" than it would to lobby purveyors of broken internet devices to really fix them. The biggest concern with a workaround, however, is that it may slow said fix. Why should we fix our firewall when your client can just use X-Method-That-Really-Is: delete? If such a workaround is implemented it should be a fallback in case a correct request fails.
It sure is frustrating that the solution is baked right in to HTTP.