W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: 305/306 response codes

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 10 Jun 1997 12:37:28 -0400
Message-Id: <199706101637.MAA01772@devnix.agranat.com>
To: Josh Cohen <josh@netscape.com>
Cc: http-wg@cuckoo.hpl.hp.com

>>>>> "JC" == Josh Cohen <josh@netscape.com> writes:

JC> * URL transformation for scope.
JC>   reversing the domain name is unlike most other formats.
JC>   The benefit here is it expresses the correct order
JC>   of diminishing significance, and allows a simple memcmp()
JC>   in implementation.
JC>   Alternatively, to acheiv eht same functionality we'd need
JC>   to allow wildcards, ie *.ups.com, which is a non-trivial
JC>   comparision, which can be costly.

  How does this work when the host part is specified as a dotted-quad
  IP address:

    http://102.55.35.19/

JC> * OPTIONS method to detect this feature.
JC>   Im not sure if this is the right way to do this.
JC>   Maybe feature negotiation instead?

JC>  1.3 506 Redirection Failed

JC>    The 506 response is returned when a redirection fails or is refused
JC>    by a proxy or client.  If the redirection response included a body,
JC>    then it SHOULD be included in the 506 response.

  I'm not clear on who sends this under what circumstances?

    A proxy after getting a request it cannot service?

  How is a redirection distinguished (by the server) from any other
  request?

JC>  3.0 Methods

JC>      A client or proxy receiving a 305 or 306, should use the OPTIONS
JC>      method to determine if the server or proxy it is talking to actu-
JC>      ally is an HTTP/1.1 server supporting 305 and 306 responses.

JC> 4.0 Operational Constraints

JC> * A webserver MUST NOT send a 306 response under any circumstances

  I assume that you mean an 'origin server' rather than a 'webserver'.

JC> * A client or proxy SHOULD NOT accept a 306 from a proxy that it
JC>   learned of via a 305 response code.

  How can it not accept it?  Presumably repeating the request will
  produce the same response... what choice does the client have?

JC>    * When receiving a 305 response, the client or proxy will enforce the
JC>      following rule with respect to the scope.

JC>      The scope specified must be more restrictive than the transformed
JC>      URL in question.

JC>      Example: (in order of restrictiveness)

JC>        http://com.ups.www/services/express/1day.html ( most restrictive)
JC>        http://com.ups.www/ (all requests for only www.ups.com )
JC>        http://com.ups ( all requests for ups.com )
JC>        http://  ( for all http requests )
JC>        *  ( all requests )

JC>      If the scope returned with a 305 response is less restrictive than
JC>      the requested URL, the client MUST prompt the user for confirmation
JC>      before accepting the new proxy setting.

JC> Security Considerations

JC> Great care should be taken when implementing client side actions
JC> based on the 305 or 306.  Since older proxies may unknowingly for-
JC> ward either of these reponses, clients should be prepared to check
JC> the validity.

JC> * A client or proxy MUST NOT accept a 305 response from a proxy.

JC> * A client or proxy MUST NOT accept a 305 response from an origin
JC>   server.

  I assume that should be

    * A client or proxy MUST NOT accept a 306 response from an origin
      server.

JC> 5.0 Notes

JC>      Further specification is needed to define exactly how to use
JC>      METHODs, or another mechanism to determin if set-proxy is sup-
JC>      ported.

  And what is the correct action for the client to take if it is not?
















































JC> J. Cohen          HTTP/1.1 305 and 306 Response Codes           [Page 8]



JC> ---LA_F48119467R-3A-865638042=:11413NCE.IlHAFeR--



--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Tuesday, 10 June 1997 09:48:19 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:44 EDT