W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

HTTP properties

From: David Orchard <dorchard@bea.com>
Date: Thu, 29 Apr 2004 02:55:45 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF071E7A76@ussjex01.amer.bea.com>
To: <www-ws-desc@w3.org>

This message contains a list of HTTP properties that may be of interest to WSDL description.  I have provided some starter comments on the relative utility of being described by WSDL.  The categories that I used are: described by WSDL 2.0, probably useful, probably not useful, not useful or applicable (n/a).  In summary, I found roughly: 4 properties that are described by WSDL 2.0, 9 probably useful categories, 2 probably not useful, and 8 not useful/application.

The properties typically related to messages.  Some may also be related to the sender or receiver role and these have generally been noted, ie httpversion is property of message sender, and ssl cyphersuite is a property of a receiver.  These sender/receiver related properties will then be realized in messages in property dependent manner.

In doing this work, I had some insights.  Firstly, there is a relationship between a property in a wsdl definition and a property in the message for a given feature, ie request-URI.  I'm not sure if WSDL would need to describe both in the context of HTTP.   Secondly, HTTP is designed for run-time negotiation.  In other words, it is designed as if WSDL, or something similar, is not available for a web site and related resources.  As a result, various properties that a receiver may wish to advertise are covered by run-time negotiation, ie content-type and allows.

List of HTTP properties:

Request-Method - described by wsdl 2.0 binding operation webmethod property 

Request-URI - described by a portion of the wsdl 2.0 binding location property

HTTP Version - probably useful to describe in an httpversion property. HTTP's version field indicates the version of the message and the capabilities of the message sender.  From rfc 2616 "The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication".  Given that HTTP 1.1 is backwards compatible with HTTP 1.0, the interesting case is where a receiver wants to advertise that it only supports 1.0 features.  See also rfc 2145

Response Status - probably useful to describe only for redirection support.  In general, it seems more useful to bind the status to the SOAP Fault infoset than to describe in WSDL 2.0.  The case that may be interesting from a WSDL perspective is redirection, see below.
Content coding(Accept-Encoding and Content-Encoding) - probably useful to describe as the encoding of the content before and after transfer is significant to applications.  

Transfer Codings(Chunked encoding) - These is probably useful to describe for sending of compressing messages.   WSDL could allow definition of codings of input and output messages.  For example, a Purchase order submission service that allowed gzip coded message in an HTTP PUT could advertise that it accepts either normal or gzip coded messages.  Without this feature, a sender that understands gzip would have to gzip the PUT and send it, and if it is an error then it send it coded normal.  The ability to describe alternate encodings allows avoidance of this classic failure followed by retry using downgraded message message pattern that has known network performance problems.  Also, it may be useful to describe support for chunked request bodies so that a sender can have a more efficient implementation.

Persistent connections - This is default but not required behaviour of HTTP 1.1.  It is probably not useful to describe in WSDL.  For example, what should a client do differently for services that support persistent connections versus those that don't that is helped by being described by WSDL? Though this could be used to advertise "policy" of connections, ie the receiver will process N requests and then drop the connection, for helping clients optimize.

Redirection - probably useful to describe.  A sender is probably interested in design-time knowledge on whether redirection is supported by a service.  

Authentication - probably useful to describe, particularly the various parameters of authentication.  For example, Basic vs. Digest vs. extension mechanism, various parameters such as realm, etc.  There seems to be a possible overlap with WS-Security.

SSL - probably useful to describe, but it is probably sufficiently described by using URIs with https.  It may be useful if WSDL described the properties of SSL, such as cyphersuites and certificate authorities.

From - probably not useful to describe.  WSDL could describe that a From field is required in a request, though this doesn't seemed used very often.  The HTTP spec specifies that From header SHOULD be a mailto: address of the human operator, but it may be interesting to generalize this for Web services.  

Caching (Vary, etc.) - probably useful to describe.  This seems potentially useful for caching the results of safe retrieval, ie GET operations.  WSDL could provide description of the caching properties of a service.  The knowledge that the operation results are cacheable could be used by a client application for client-side caching.  However, this may not be very useful.  If a Web service provides a cacheable operation, then the client will know from the resulting http headers.  This seems like metadata to help a client implementation and the service deployment, but is not required for interoperability.  

Content Negotiation (Content-Type and Accept) - probably useful to describe, particularly useful for indicating use of the MTOM mechanism.  An HTTP Web service may want to describe the types that it will return for a given URI and then a client can set the accept.  This would provide design time information to the client.  However, this doesn't seem too useful in general from a Web services perspective.  This allows a client and server to negotiate a hypertext format for exchange without knowing ahead of time what formats are available.  In Web services, a service that wants to return format X versus format Y for a given request will typically create multiple methods, ie getX and getY.  It might be possible for WSDL to allow the "normal" description of operations, ie getX and getY, and then binding operation that binds to the two operations to the same binding operation and setting the Accept header to either X or Y.  In the case of HTTP GET, the only parameter of the operation would be the type requested, and this would be sent as the accept header.  Perhaps the binding operation would have an "accept" property?  There is also a mismatch between HTTP's use of MIME types and WSDL's use of XML Qnames for types.  The Content-type is potentially tricky as it be the differentiator on the return, so the receiver would have to use it to determine which operation was invoked.  This is somewhat similar to function return overloading.

Host - described by a subset of the wsdl location property.  

Content-Range - not useful to describe. 

If-* - not useful to describe.  Meant for cache validation of existing content, so can't be specified in WSDL.
Max-Forwards - not useful to describe.

Expect - not useful to describe.  The same functionality is provided in SOAP. But would it make sense for someone in the SOAP infoset to want to put in an Expect that alters HTTP behavior? How much of the transport do we want to leak through into the SOAP infoset?

Upgrade - not useful to describe.  This duplicates WSDL functionality of bindings where a client can request a different protocol for subsequent interactions.

Via - not useful to describe.  This is a run-time informational report of what intermediaries a message has passed through.

Warning - not useful to describe.  

Allow - probably not useful to describe.   This seems to duplicate some of WSDL functionality as this allows a server to indicate which operations are allowed on a given resource.  A service could generate Allow headers for resources that WSDL has described as there will be sufficient information in the WSDL binding to populate this header.  This implies the client does not have the WSDL and so this seems of limited utility.

Content-Language, Content-Location, Content-MD5, Date, Etag, Expires, Last-Modified, Referrer, Retry-After - not useful to describe.

Server, User-Agent - probably not useful to describe.  It might be useful to have the software used to implement the Web service identified in the messages.

Partial Content - not useful to describe.  

Content-disposition - probably not useful to describe.

PICS, P3P - not useful to describe.  These are straight Policy.  http://lists.w3.org/Archives/Public/public-p3p-spec/2004Apr/0016.html

SoapAction - described in WSDL SOAP binding.  WSDL SOAP Binding SOAPAction property

Cookies - probably useful to describe.  Description could be used to indicate support or requirements for the use of HTTP stateful cookies.

WebDAV - probably not useful to describe.   Not used with Web services currently, though perhaps it should be.

Delta Encoding - ?
Received on Thursday, 29 April 2004 05:55:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC