pymeds/docs/draft-goland-http-udp-04.txt

UPnP Forum Technical Committee                          Yaron Y. Goland 
Document: draft-goland-http-udp-04.txt                        CrossGain 
                                                   Jeffrey C. Schlimmer 
                                                              Microsoft 
                                                        02 October 2000 
 
 
                Multicast and Unicast UDP HTTP Messages 
 
 
Status of this Memo 
    
   This document is under review by the UPnP Forum Technical Committee. 
   It was previously submitted to the IETF as an Internet Draft and has 
   expired. This document is formatted in a manner consistent with the 
   IETF formatting guidelines to facilitate possible future 
   consideration by the IETF. 
    
   This document is available on http://www.upnp.org. 
    
Abstract 
    
   This document provides rules for encapsulating HTTP messages in 
   multicast and unicast UDP packets to be sent within a single 
   administrative scope. No provisions are made for guaranteeing 
   delivery beyond re-broadcasting. 
    
1. Introduction 
    
   This document provides rules for encapsulating HTTP messages in 
   multicast and unicast UDP messages. No provisions are made for 
   guaranteeing delivery beyond re-broadcasting. 
    
   This technology is motivated by applications such as SSDP where it 
   is expected that messages which are primarily transmitted over TCP 
   HTTP need to be transmitted over Multicast or Unicast UDP, because 
   of the unique requirements of extremely lightweight servers. 
    
   This document will not specify a mechanism suitable for replacing 
   HTTP over TCP. Rather this document will define a limited mechanism 
   only suitable for extreme circumstances where the use of TCP is 
   impossible. Thus this mechanism will not have the robustness of 
   functionality and congestion control provided by TCP. It is expected 
   that in practice the mechanisms specified here in will only be used 
   as a means to get to TCP based HTTP communications. 
    
2. Changes 
    
2.1. Since 00 
    
   Divided each section of the spec into three parts, problem 
   definition, proposed solution and design rationale. When the spec is 
   ready for standardization the problem definition and design 
   rationale sections will be removed. Design rationale is presented in 
  
Goland, Schlimmer                                                    1 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   question/answer form because I have found that to be very effective 
   in addressing design issues. 
    
   Clarified that a HTTPU/HTTPMU URI without an abs_path translates to 
   "*" in the request-URI. 
    
   Added the S header to allow request and responses to be associated. 
   Note that while clients aren't required to send out S headers, 
   servers are required to return them. 
    
   Got rid of MM. The lower bound is always 0. 
    
   The introduction of the S header makes proxying and caching possible 
   so the sections on those topics have been expanded, but they should 
   be considered experimental at best. 
    
2.2. Since 02 
    
   Added requirement for HTTP/1.1 as the version identifier in the 
   request line. (See section on HTTP Version in Request Line.) 
    
   Removed requirement that requests without an S header MUST NOT be 
   responded to. (See section on Unicast UDP HTTP Messages.) 
    
   Clarified that a server should respond to each request it receives 
   but not duplicate those responses. (See section on Retrying 
   Requests.) 
    
   Clarified caching when responding to repeated requests. (See section 
   on Caching.) 
    
   Expanded that if a server has > 1 response per HTTPMU request, it 
   should spread them out. (See section on MX header.) 
    
   Tied behavior of duplicate responses with the same S header value to 
   the semantics of the method (was discard duplicates). (See section 
   on S header.) 
    
   Outlined initial security considerations. (See section on Security.)  
    
2.3. Since 03 
   Clarified the "no abs_path" requirement for HTTPU/HTTPMU request-
   URIs. 
    
   Clarified use of "*" as a request-URI. 
    
   Removed requirement for HTTPU/HTTPMU servers to support "chunked" 
   transfer-coding. 
    
3. Terminology 
    
   Since this document describes a set of extensions to the HTTP/1.1 
   protocol, the augmented BNF used herein to describe protocol 
     
Goland, Schlimmer                                                    2 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   elements is exactly the same as described in section 2.1 of 
   [RFC2616]. Since this augmented BNF uses the basic production rules 
   provided in section 2.2 of [RFC2616], these rules apply to this 
   document as well. 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [RFC2119]. 
    
4. HTTPU URL 
    
4.1. Problem Definition 
    
   A mechanism is needed to allow for communications that are to be 
   sent over Unicast UDP HTTP to be identified in the URI namespace. 
    
4.2. Proposed Solution 
    
   The HTTPU URL specifies that the HTTP request be sent over unicast 
   UDP according to the rules laid out in this document. 
    
   HTTPU_URL = "HTTPU:" "//" host [ ":" port ] [ abs path [ "?" query]] 
    
   The BNF productions host, port and abs path are defined in 
   [RFC2616]. 
    
   The syntax of the HTTPU URL is to be processed identically to the 
   HTTP URL with the exception of the transport. 
    
   One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are 
   identical in all ways save the protocol that they necessarily point 
   to the same resource. 
    
4.3. Design Rationale 
    
4.3.1. Why would we ever need a HTTPU/HTTPMU URL? 
    
   Imagine one wants to tell a system to send responses over HTTPU. How 
   would one express this? If one uses a HTTP URL there is no way for 
   the system to understand that you really meant HTTPU. 
    
5. HTTPMU URL 
    
5.1. Problem Definition 
    
   A mechanism is needed to allow for communications that are to be 
   sent over Multicast UDP HTTP to be identified in the URI namespace. 
    
5.2. Proposed Solution 
    
   The HTTPMU URL specifies that the HTTP request that HTTP request is 
   to be sent over multicast UDP according to the rules laid out in 
   this document. 
     
Goland, Schlimmer                                                    3 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
    
   HTTPMU_URL = "HTTPMU:" "//" host [ ":" port ] [ abs path [ "?" 
   query]] 
    
   The BNF productions host, port and abs path are defined in 
   [RFC2616]. 
    
   The syntax of the HTTPMU URL is to be processed identically to the 
   HTTP URL with the exception of the transport. 
    
   One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are 
   identical in all ways save the protocol that they necessarily point 
   to the same resource. 
    
   If a HTTPMU URL does not have an abs path element then when the HTTP 
   multicast UDP request is made the request-URI MUST be "*". 
    
   For example, HTTPU://www.foo.com would translate into a request-URI 
   of "*". A request-URI of HTTPU://www.foo.com/ would still translate 
   to the absoluteURI "HTTPU://www.foo.com/". 
    
5.3. Design Rationale 
    
5.3.1. In the HTTPMU URL a request such as http://www.foo.com is 
      translated to a "*" in the request-URI rather than a "/", why 
      isn't the same the case for HTTPU? 
    
   A HTTPU request is a point-to-point request. There is one sender and 
   one receiver. Thus the semantics of the URL are identical to HTTP 
   with the exception of the transport. 
    
   Generally, a HTTPMU client will want to send its request to many 
   receivers at once, where each receiver represents a different set of 
   resources. A client can specify this in the HTTPMU request itself by 
   using the request-URI "*". Unfortunately, there is no present way to 
   construct an HTTP URL that will have this request-URI. As such, a 
   mechanism had to be added. 
    
5.3.2. Why would an HTTPMU client want to use a request-URI of "*" 
       anyway? 
    
   In TCP HTTP, the client will often specify a single resource on 
   which the request should operate. For example, a GET of the URL 
   http://foo.org/baz.gif should retrieve the resource at that single, 
   well-defined location. 
    
   One big reason for a client to send a request over multicast UDP, 
   though, is the ability to send a request to many receivers at once, 
   even when the number of receivers is not known. 
    
   Specifying an absoluteURI in the request, though, would defeat this; 
   all receivers without that exact resource would be forced to reject 
   the request. 
     
Goland, Schlimmer                                                    4 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
    
   By specifying a request-URI of "*" client signifies that the request 
   "does not apply to a particular resource, but to the server itself, 
   and is only allowed when the method used does not necessarily apply 
   to a resource." [RFC 2616] 
    
5.3.3. So when would an HTTPMU client want to use a request-URI other 
       than "*"? 
    
   This may be useful when a client knows the URI for the resource, but 
   not the server on which the resource lives. If the client knows 
   both, though, it is expected that TCP HTTP or HTTPU would be used. 
    
   Servers MUST NOT assume that an HTTPMU request containing an 
   absoluteURI necessarily refers to the same resource as a HTTPU 
   request with the same absoluteURI. For example, servers that support 
   both HTTPMU and HTTPU may reject a request for a particular resource 
   when received through HTTPMU, but accept it when received through 
   HTTPU. 
6. HTTP Version in Request Line 
    
6.1. Problem Definition 
    
   A message format identifier is needed for the HTTPU and HTTPMU 
   request lines. 
    
6.2. Proposed Solution 
    
   Request lines for HTTPU and HTTPMU requests MUST use HTTP/1.1 as the 
   version. 
    
   Request-Line = Method SP Request-URI SP HTTP/1.1 CRLF 
    
   The BNF production Method is defined in [RFC2616]. 
    
6.3. Design Rationale 
    
6.3.1. Why not define separate HTTPU and HTTPMU versions? 
    
   While HTTP/1.1 does hint at underlying features (like pipelining), 
   it principally specifies a message format. HTTPU and HTTPMU use the 
   same message format as defined by HTTP/1.1. Reusing this message 
   format identifier enables syntactic parsing / generating of HTTPU 
   and HTTPMU request by existing HTTP message mungers. 
    
6.3.2. If the version in the request line is the same as an HTTP 
       request, once a request was stored, how could one distinguish an 
       HTTPU (or HTTPMU) request from an HTTP request? 
    
   TBD 
    
7. Unicast UDP HTTP Messages 
    
     
Goland, Schlimmer                                                    5 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
7.1. Problem Definition 
    
   A mechanism is needed to send HTTP messages over the unicast UDP 
   transport. 
    
7.2. Proposed Solution 
    
   HTTP messages sent over unicast UDP function identically to HTTP 
   messages sent over TCP as defined in [RFC2616] except as specified 
   below. 
    
   For brevity's sake HTTP messages sent over unicast UDP will be 
   referred to as HTTPU messages. 
    
   HTTPU messages MUST fit entirely in a single UDP message. If a HTTPU 
   message can not be fit into a single UDP message then it MUST NOT be 
   sent using unicast UDP. Incomplete HTTPU messages SHOULD be ignored. 
    
   The request-URI of a HTTPU message MUST always be fully qualified. 
    
   A single unicast UDP message MUST only contain a single HTTPU 
   message. As such, an HTTPU server MAY reject messages with "chunked" 
   transfer-coding. 
   When responding to a HTTPU request with an S header the rules for 
   the proper handling of S headers, as specified below MUST be 
   followed. 
    
7.3. Design Rationale 
    
   See also the subsection on the S header below for the design 
   rationale of the S header. 
    
7.3.1. Why can't a single HTTP message be sent over multiple UDP 
       messages? 
    
   The ability to send unlimited size messages across the Internet is 
   one of the key features of TCP. The goal of this paper is not to 
   reinvent TCP but rather to provide a very simple emergency back up 
   HTTP system that can leverage UDP where TCP cannot be used. As such 
   features to allow a single HTTP message to span multiple UDP 
   messages is not provided. 
    
7.3.2. Why are request-URIs sent over HTTPU required to be fully 
       qualified? 
    
   A relative URI in a HTTP message is assumed to be relative to a HTTP 
   URL. However this would clearly be inappropriate for a HTTPU or 
   HTTPMU message. The easiest solution would be to simply state that a 
   relative URI is relative to the type of message it was sent in. But 
   one of the goals of this draft is to allow current HTTP message 
   processors to be able to munch on HTTPU/HTTPMU messages and this 
   would cause a change to those processors. 
    
     
Goland, Schlimmer                                                    6 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   The cost of this simplification is that you repeat the host 
   information, once in the URI and once in the host header.  
   But again, taking out the host header would make a lot of existing 
   HTTP message munchers very unhappy. 
    
7.3.3. Why is the requirement for ignoring incomplete HTTPU messages a 
      SHOULD instead of a MUST? 
    
   Some systems use a lot of redundant data or have good mechanisms for 
   handling partial data. As such they could actually do something 
   intelligent with a partial message. A SHOULD allows them to do this 
   while still making it clear that in the majority case partial 
   HTTPU/HTTPMU messages are going to get thrown out. 
    
7.3.4. Why aren't multiple HTTP messages allowed into a single UDP 
       message if they will fit? 
    
   It was easier to ban it, and it didn't seem to buy us much. It was 
   especially worrying because it would start to convince people that 
   they could actually order their UDP requests in a pipelinesque 
   manner. It was easier to just keep things simple and ban it. 
    
7.3.5. Why aren't we allowed to leave off content-lengths if only a 
       single HTTPU message is allowed in a UDP message? 
    
   In general we try to only change from RFC 2616 when we are forced 
   to. Although including a content-length is annoying it makes it easy 
   to use HTTP/1.1 message parsing/generating systems with this spec. 
    
7.3.6. Why might a HTTPU message choose to not have an S header? 
    
   Leaving off the S header would be useful for throwaway events. In 
   systems with a high event rate it is usually easier to just throw 
   away an event rather than re-sending it. As such there is no real 
   benefit to correlating unnecessary responses with requests. 
    
7.3.7. Why isn't the MX header used on HTTPU messages? 
    
   As HTTPU messages are point-to-point there will be exactly one 
   response. MX is only useful in cases, such as HTTPMU requests, where 
   there can be many potential responses from numerous different 
   clients. MX helps to prevent the client from getting creamed with 
   responses. 
    
7.3.8. Can I send 1xx responses over HTTPU? 
    
   Yes. Error handling is identical to RFC 2616. 
    
8. Multicast UDP HTTP Requests 
    
8.1. Problem Definition 
    

     
Goland, Schlimmer                                                    7 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   A mechanism is needed to send HTTP messages over the multicast UDP 
   transport. 
    
8.2. Proposed Solution 
    
   HTTP messages sent over multicast UDP MUST obey all the requirements 
   for HTTPU messages in addition to the requirements provided below. 
    
   For brevity's sake HTTP messages sent over multicast UDP will be 
   referred to as HTTPMU messages. 
    
   Resources that support receiving multicast UDP HTTP requests MUST 
   honor the MX header if included in the request.  
    
   If a resource has a single response, it MUST generate a random 
   number between 0 and MX that represents the number of seconds the 
   resource MUST wait before sending a response. If a resource has 
   multiple responses per request, it SHOULD send these resources 
   spread over the interval [0..MX]. This prevents all responses from 
   being sent at once.  
    
   HTTP clients SHOULD keep listening for responses for a reasonable 
   delta of time after MX. That delta will be based on the type of 
   network the request is being sent over. This means that if a server 
   cannot respond to a request before MX then there is little point in 
   sending the response, as the client will most likely not be 
   listening for it. 
    
   When used with a multicast UDP HTTP request, the "*" request-URI 
   means "to everyone who is listening to this IP address and port." 
    
   A HTTPMU request without a MX header MUST NOT be responded to. 
    
8.3. Design Rationale 
    
8.3.1. Why is there a "delta" after the MX time when the client should 
       still be listening? 
    
   So let's say the MX value is 5 seconds. The HTTP resource generates 
   a number between 0 and 5 and gets 5. After 5 seconds of waiting the 
   HTTP resource will send its response. 
    
   Now for some math: 
    
     0.5 seconds         - Time it took the client's request to reach 
                           the HTTP resource. 
     5 seconds           - Time the HTTP resource waited after 
                           receiving the message to respond, based on 
                           the MX value. 
     0.5 seconds         - Time for the response to get back to the 
                           client. 
   Total time elapsed   - 6 seconds 
    
     
Goland, Schlimmer                                                    8 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   If the client only waits 5 seconds, the MX value, then they would 
   have stopped listening for this response by the time it arrived, 
   hence the need for the delta. 
    
8.3.2. What should the "delta" after MX expires be? 
    
   Unfortunately this is an impossible question to answer. How fast is 
   your network? How far is the message going? Is there any congestion? 
   In general delta values will be set based on a combination of 
   heuristics and application necessity. That is, if you are displaying 
   information to a user any data that comes in after 20 or 30 seconds 
   is probably too late. 
    
8.3.3. When would a HTTPMU request not be responded to? 
    
   When a HTTP resource is making a general announcement, such as "I am 
   here", it generally isn't useful to have everyone respond confirming 
   they received the message. This is especially the case given that 
   the HTTP resource probably doesn't know who should have received the 
   announcement so the absence of a HTTP client in the responses 
   wouldn't be meaningful. 
    
   Whether a particular request requires a response is dependant on the 
   application, and is beyond the scope of this specification. 
    
8.3.4. Why do we require the MX header on HTTPMU requests that are to 
       be responded to? 
    
   This is to prevent overloading the HTTP client. If all the HTTP 
   resources responded simultaneously the client would probably loose 
   most of the responses as its UDP buffer overflowed. 
    
9. Retrying Requests 
    
9.1. Problem Definition 
    
   UDP is an unreliable transport with no failure indicators; as such 
   some mechanism is needed to reasonably increase the chance that a 
   HTTPU/HTTPMU message will be delivered. 
    
9.2. Proposed Solution 
    
   UDP is an inherently unreliable transport and subject to routers 
   dropping packets without notice. Applications requiring delivery 
   guarantees SHOULD NOT use HTTPU or HTTPMU.  
    
   In order to increase the probability that a HTTPU or HTTPMU message 
   is delivered the message MAY be repeated several times. If a 
   multicast resource would send a response(s) to any copy of the 
   request, it SHOULD send its response(s) to each copy of the request 
   it receives. It MUST NOT repeat its response(s) per copy of the 
   reuqest. 
    
     
Goland, Schlimmer                                                    9 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   In order to prevent the network from being flooded a message SHOULD 
   NOT be repeated more than MAX_RETRIES time. A random period of time 
   between 0 and MAX_RETRY_INTERVAL SHOULD be selected between each 
   retry to determine how long to wait before issuing the retry.  
    
9.3. Design Rationale 
    
9.3.1. Why is the requirement "applications requiring delivery 
       guarantees should not use HTTPU or HTTPMU" only a SHOULD and not 
       a MUST? 
    
   Because there might come a day when it makes sense to use HTTPU or 
   HTTPMU for guaranteed delivery and there is no reason to completely 
   ban the possibility. 
    
9.3.2. Why is the requirement that a request not be repeated more than 
       MAX_RETRIES times a SHOULD and not a MUST? 
    
   Local knowledge may make the limit unnecessary. For example, if one 
   knew that the message was being delivered using a super reliable 
   network then repeats are not necessary. Similarly if one knew that 
   the network the requests were going through were particularly 
   unreliable and assuming one had properly accounted for the effects 
   of additional messages on that congestion, one might have a good 
   reason to send more than MAX_RETRIES. 
    
9.3.3. Why SHOULD multicast resources respond to each copy of a request 
       it receives? 
    
   Because the earlier responses might have been lost. 
    
9.3.4. Why MUST multicast resources not repeat its response(s) to each 
       copy of a request it receives? 
    
   This strategy provides the lowest network loading for any desired 
   level of reliability, or equivalently, the highest reliability for 
   any specified level of network loading. 
    
10. Caching 
    
10.1. Problem Definition 
    
   Caching is a feature that has demonstrated its usefulness in HTTP, 
   provisions need to be made to ensure that HTTPU/HTTPMU messages can 
   be cached using a consistent algorithm. 
    
10.2. Proposed Solution 
    
   [Ed. Note: Never having tried to actually build a HTTPU/HTTPMU 
   generic cache we suspect there are some very serious gotchas here 
   that we just haven't found yet. This section should definitely be 
   treated as "under development."] 
    
     
Goland, Schlimmer                                                   10 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   Caching rules for HTTPU/HTTPMU responses are no different than 
   normal HTTP responses. HTTPU/HTTPMU responses are matched to their 
   requests through the S header value. 
    
   When responding to a multicast request, a resource MAY cache its 
   response(s) and retransmit from the cache in response to duplicate 
   requests. 
    
10.3. Design Rationale 
    
10.3.1. Wouldn't it be useful to be able to cache HTTPU/HTTPMU requests 
       if they don't have responses? 
    
   Yes, it probably would, especially if we are talking about a client-
   side cache. It is probably worth investigating the use of cache 
   control headers on requests for this very purpose. 
    
11. Proxying UDP HTTP Requests 
    
11.1. Problem Definition 
    
   For security or caching reasons it is sometimes necessary to place a 
   proxy in a message path. Provisions need to be made to ensure that 
   HTTPU/HTTPMU messages can be proxied. 
    
11.2. Proposed Solution 
    
   [Ed. Note: This section should be considered experimental. No one 
   has really had to design much less implement a HTTPU/HTTPMU proxy 
   yet.] 
    
   All transport independent rules for proxying, such as length of time 
   to cache a response, hop-by-hop header rules, etc. are the same for 
   HTTPU/HTTPMU as they are for HTTP messages. 
    
   [Ed. Note: I'm not sure how far to go into the "transport 
   independent rules". The RFC 2616 doesn't really call them out very 
   well but I also don't want to have to re-write RFC 2616 spec inside 
   this spec.] 
    
   The transport dependent rules, however, are different. For example, 
   using TCP any pipelined messages are guaranteed to be delivered in 
   order. There are no ordering guarantees of any form for HTTPU/HTTPMU 
   proxies. 
    
   In general a proxy is required to forward a HTTPU/HTTPMU message 
   exactly once. It SHOULD NOT repeat the message. Rather the client is 
   expected to repeat the message and, as the proxy receives the 
   repeats, they will be forwarded. 
    
   Note that it is acceptable, if not encouraged, for proxies to 
   analyze network conditions and determine the likelihood, on both 
   incoming and outgoing connections, of UDP messages being dropped. If 
     
Goland, Schlimmer                                                   11 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   the likelihood is too high then it would be expected for the proxy, 
   taking into consideration the possibility of making congestion even 
   worse, to repeat requests and responses on its own. In a sense the 
   proxy could be thought of as a signal regenerator. This is why the 
   prohibition against repeating messages is a SHOULD NOT rather than a 
   MUST NOT. 
    
   HTTPMU messages are sent with the assumption that the message will 
   only be seen by the multicast address they were sent to. Thus when a 
   proxy forwards the request it is expected to only do so to the 
   appropriate multicast channel. Note, however, that proxies may act 
   as multicast bridges. 
    
   Also note that proxied HTTPMU messages with a HTTPMU URL without an 
   absolute path are to be treated as if they were sent to the 
   specified multicast address with the request-URI "*". 
    
   If a HTTPMU request is sent with a host that does not resolve to a 
   multicast address then the request MUST be rejected with a 400 Bad 
   Request error. 
    
   There is no requirement that a HTTPU proxy support HTTPMU or vice 
   versa. 
    
11.3. Design Rationale 
    
11.3.1. Why would anyone proxy HTTPMU requests? 
    
   Proxying HTTPMU requests can be a neat way to create virtual 
   multicast channels. Just hook a bunch of proxies together with 
   unicast connections and tell the proxies' users that they are all on 
   the same multicast scope. 
    
12. HTTP Headers 
    
12.1. AL (Alternate Location) General Header 
    
12.1.1. Problem Definition 
    
   There are many instances in which a system needs to provide location 
   information using multiple URIs. The LOCATION header only allows a 
   single URI. Therefore a mechanism is needed to allow multiple 
   location URIs to be returned. 
    
12.1.2. Proposed Solution 
    
   AL = "AL" ":" 1*("<" AbsoluteURI ">") ; AbsoluteURI is defined in 
   section 3.2.1 of [RFC2616] 
    
   The AL header is an extension of the LOCATION header whose semantics 
   are the same as the LOCATION header. That is, the AL header allows 
   one to return multiple locations where as the LOCATION header allows 
   one to return only one. The contents of an AL header are ordered. If 
     
Goland, Schlimmer                                                   12 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   both a LOCATION header and an AL header are included in the same 
   message then the URI in the LOCATION header is to be treated as if 
   it were the first entry in the AL header. The AL header MAY be used 
   by itself but implementers should be aware that existing systems 
   will ignore the header. 
    
12.1.3. Design Rationale 
    
12.1.3.1. Why not just fix the BNF for the LOCATION header? 
    
   This is tempting but the goal of maintaining compatibility with RFC 
   2616's message format overrides the usefulness of this solution. 
    
12.2. MX Request Header 
    
12.2.1. Problem Definition 
    
   A mechanism is needed to ensure that responses to HTTPMU requests do 
   not come at a rate greater than the requestor can handle. 
    
12.2.2. Proposed Solution 
    
   MX = "MX" ":" Integer 
   Integer = First_digit *More_digits 
   First_digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 
   More_digits = "0" | First_digit 
    
   The value of the MX header indicates the maximum number of seconds 
   that a multicast UDP HTTP resource MUST wait before it sends a 
   response stimulated by a multicast request. 
    
   HTTP resources MAY treat any MX header value greater than MX_MAX as 
   being equal to MX_MAX. 
    
12.2.3. Design Rationale 
    
12.2.3.1. Why is MX in seconds? 
    
   In practice wait periods shorter than a second proved useless and 
   longer proved too coarse. Of course as faster networks get deployed 
   finer-grain times would be useful, but we need a compromise 
   measurement that will meet everyone's needs. Seconds seem to do that 
   quite well. 
    
12.2.3.2. Couldn't MX still overload the requestor if there are too 
          many responders? 
    
   Absolutely. If there are a 100,000 clients that want to respond even 
   pushing them over 30 seconds on a 10 Mbps link is still going to 
   blow both the client and the network away. However the only way to 
   prevent these sorts of situations is to know the current available 
   network bandwidth and the total number of likely responders ahead of 

     
Goland, Schlimmer                                                   13 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
   time. Both generally prove between difficult to impossible to figure 
   out. So we are left with heuristics and the MX header. 
    
12.3. S (Sequence) General Header 
    
12.3.1. Problem Definition 
    
   A mechanism is needed to associate HTTPU/HTTPMU requests with 
   responses, as UDP does not have any connection semantics. 
    
12.3.2. Proposed Solution 
    
   S = "S" ":" AbsoluteURI 
    
   The S header is a URI that is unique across the entire URI namespace 
   for all time. When an S header is sent on a HTTPU/HTTPMU request it 
   MUST be returned, with the same value, on the response. 
    
   If a client receives multiple responses with the same S header then 
   the client MAY assume that all the responses are in response to the 
   same request. If the messages differ from each other then the client 
   MUST behave based on the specification of the request method. 
    
12.3.3. Design Rationale 
    
12.3.3.1. Why do we need the S header? 
    
   Without an S header the only way to match requests with responses is 
   to ensure that there is enough information in the response to know 
   what request it was intended to answer. Even in that case it is 
   still possible to confuse which request a response goes to if it 
   does not have the equivalent of an S header. 
    
12.3.3.2. Why aren't S headers mandatory on all requests with a 
          response? 
    
   Some systems don't need them. 
    
12.3.3.3. Why aren't S headers guaranteed to be sequential so you could 
          do ordering? 
    
   Because HTTPU/HTTPMU is not interested in ordering. If one wants 
   ordering one should use TCP. 
    
12.3.3.4. Do S headers allow detecting and removing duplicates? 
    
   Yes, for methods (like GET) that define a single responses to a 
   request. No, for methods (like SEARCH) that define multiple 
   responses to a request. 
    
13. Interaction of HTTP, HTTPU and HTTPMU Messages 
    
13.1. Problem Definition 
     
Goland, Schlimmer                                                   14 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
    
   [Ed. Note: Concerns include HTTPU request redirected to HTTP? > 1 
   HTTPU responses to 1 HTTPMU request?] 
    
13.2. Proposed Solution 
    
   TBD 
    
13.3. Design Rationale 
    
   TBD 
    
14. Security Considerations 
    
   All the normal HTTP security considerations apply. 
    
14.1. Cookies 
    
   There is no danger that the S header will be used as a cookie since 
   the client generates it, and the server returns it. (A cookie is 
   generated by a server and returned by the client.) 
14.2. Spoofing 
    
   Servers and multicast resources could fake S headers, but this is 
   not a major threat if some form of authentication over UDP is used. 
   (Defining authentication over UDP is beyond the scope of this 
   document, but briefly, one could assume the challenge and send the 
   authentication response as part of the HTTPU/MU request.) 
    
14.3. Lost Requests 
    
   TBD 
    
14.4. Oversized Requests 
    
   TBD 
    
15. Acknowledgements 
    
   Thanks to John Stracke for his excellent comments. Dale Worley 
   devised the single-response-per-each-copy-of-request mechanism 
   outlined in the section on Retrying Requests. Chris Rude clarified 
   request URI rules. 
    
16. Constants 
    
   MAX_RETRIES - 3 
    
   MAX_RETRY_INTERVAL - 10 seconds 
    
   MAX_MX - 120 seconds 
    
17. Reference 
     
Goland, Schlimmer                                                   15 
UPnP Forum                     UDP HTTP                    24 Aug 2000 
 
 
    
   [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 
   Requirement Levels. RFC 2119, March 1997. 
    
   [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 
   Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol - 
   HTTP/1.1. RFC 2616, November 1998. 
    
18. Authors' Address  
    
   Yaron Y. Goland 
   CrossGain 
   2039 152nd Avenue NE 
   Redmond, WA 98052 
   <mailto:yarongo@crossgain.com> 
    
   Jeffrey C. Schlimmer 
   Microsoft Corporation 
   One Microsoft Way 
   Redmond, WA 98052 
   <mailto:jeffsch@microsoft.com> 
































     
Goland, Schlimmer                                                   16