Summary of comments on two findings (contentTypeOverride-24, whenToUseGet-7)

Dear TAG,

At our 2 June meeting, I would like to talk about the status of
two draft findings:

 - Client handling of MIME headers [1]
 - URIs, Addressability, and the use of HTTP GET and POST [2]

I've summarized comments below. There has been support for both
of these and no objections. However, since we are waiting to hear
from the Voice Browser WG and still in discussion with them, I
don't think that we are ready to approve [1].

Many thanks to those who have read and commented on these
draft findings.

 - Ian


Client handling of MIME headers

1) There was a suggestion that the finding also talk
   about headers in the direction client-to-server. Does
   the principle apply to those headers as well?

   This discussion spawned a thread on what a server should do
   when the client doesn't send a mime header, or if the PUT is
   inconsistent with the server configuration. Roy suggested
   signaling an error.

   That discussion spawned a thread about whether a server
   must serve content with the same mime type used to
   PUT it.  See Noah's proposed explanation [3]. This in turn
   spawned a discussion of PUT meaning "set" or "store." There 
   was a proposal [4] from Mark Baker for a new issue on
   PUT semantics and mime header handling. Noah proposed 
   language [5].

    a) Should the finding say anything about client-to-server

    b) Should the finding say anything about the PUT scenarios
       that were discussed?

2) E. R. Harold requested a clarification to one of the scenarios


3) I think the finding should address issues of "local override"
   of headers. Some examples where instructions in content
   seem to override headers (if so, why ok? if not, why not?).

        - xml:lang
        - SCRIPT/type in HTML 
        - Mixed content

4) We should  include a comment that the SMIL 1.0 Recommendation 
   (and possibly others?) does not do the right thing in
   this area.

   Also, in HTML 4.01, META/http-equiv can be used by servers to
   generate an HTTP header (see section 7.4.4 [7], subsection
   "META and HTTP headers"). This might be a source of confusion
   because the META element is supposed to be interpreted
   server-side, not client-side. 

5) From Tim Bray:

   - Add note about use of RFC2119 terms.

   - Sugested tweaking language around
    "engaging in non-authoritative behavior" in section 4.

   - We need to expand this to talk up the security 
     issues a bit. 

     Tim Bray, could you say more about this?

6) From Roy at the 12 May teleconf [8]: Roy cited "efficiency"
   as a reason why the architecture makes server headers
   authoritative. The draft finding does not make the efficiency
   argument and probably shoul.


URIs, Addressability, and the use of HTTP GET and POST

1) Suggested text from Noah to replace current text about ongoing
   work in SOAP/WSDL [9]. However, DO doesn't agree with 
   perception  that GET=non-rpc and POST=rpc.  See Noah's 
   follow-up [10]. I'm not sure how to proceed.


2) Noah also requests [9] that the finding be clearer about
   PUT (which currently isn't mentioned). Should the finding 
   simply state that it doesn't cover PUT, or should it try
   to provide some guidance on PUT v. POST? Or just point to
   the HTTP spec?

Ian Jacobs (
Tel:                     +1 718 260-9447

Received on Thursday, 29 May 2003 14:50:20 UTC