- From: David W. Morris <dwm@shell.portal.com>
- Date: Thu, 29 Aug 1996 09:01:03 -0700 (PDT)
- To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Thu, 29 Aug 1996, John Franks wrote: > As you observe server support for digest auth is widely available. > The reason no one uses it is because it is not supported by Netscape > or MSIE -- period. As long as this remains the case digest will never I think we have a bit of a chicken and egg problem. Server software is available which is claimed to support digest but it is not activated by real installations because the majority of users don't have clients which will support it *AND* apparently the server installation can't, at least easily, support basic and digest concurrently. On the otherhand, the client authors can't find a set of easy places to test their code with so the clients don't include the code. In my experience, it is very rare for a development organization to have the resources to do everything the know to be right to do. I also find that the QA groups are even more stressed. In particular, the QA group may have learned how to test the browser but don't have the skills to set up many varieties of servers. I would expect that testing would focus on a very few servers and then depend on WWW deployed servers for surface verification with others. After all, if http is an interoperable protocol, it should be sufficient to test with one server. This group is a bit two faced. A couple weeks a go, a prominant member was chastising folks who might be publishing a server and calling it HTTP/1.1 before the very stable draft is really approved by the IETF. Now we are complaining because one or more other software publishers chose not to deliver software matching a spec about which discussion had gotten very hot and might be expected to be an unstable implementation target. C'mon folks we can't have it both ways! I think there is some obvious room here for W3C activity in the form of facilitating the testing of client and server implementation of digest. 1. Bring up and make 'public' a copy of each of the servers which claim to implement digest, with digest active of course. 2. I believe there is at least one publicly available client which also claims to support digest. Help any interested developers install and use such clients. If necessary because of platform difficulties, use the client against a developers server. 3. Do both of the above with appropriate diagnostic tools such as sniffers available to facilitate diagnosis of the failure to interoperate. 4. Provide some level of consulting services to help with problem determination. Of course, this is still difficult because I would expect that most developers and QA groups are behind firewalls which might not be real friendly to such testing. One could hope that the server and client teams within a organization might cooperate but I would guess that the product manager at one publisher for the server might have different priorities from the client in the same organization. Surely the client needs the support at least a generation sooner than the server. And in any case, I would worry that just because AAclient works with AAserver, they may not operate with BBserver or BBclient. So in summary, if we as a WG think deployment of digest is important, then I think we need to forget about the political implications of SHOULD vs MUST and somehow forcing publishers to do it our way and figure out how to facilitate the environment needed for publishers to successfully develop, test, and ship digest enabled software. Dave Morris
Received on Thursday, 29 August 1996 09:06:01 UTC