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

Re: 305/306 response codes

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Sun, 15 Jun 1997 19:47:28 -0700
To: Josh Cohen <josh@netscape.com>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9706151948.aa09417@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3540
In general:  "header" and "headers" are synonyms for the entire message
header (as opposed to the body), whereas 'Set-proxy' is a "header field",
or just "field".  I see the same confusion of terms in just about every
proposal to change HTTP, but it would be nice to stay consistent with
what I wrote for HTTP (based on what Ned wrote for MIME).

>   The 305 is generated by an origin server to indicate that the client,
, or a firewall upon receipt of a misdirected request, 

>   If the 305 response is not accompanied by a 'Set-proxy' header, it
>   MUST be accompanied by a 'Location' header.  The 'Location' header
>   will specify a URL to the proxy.

Is this for backwards-compatibility with something (besides the spec)?
If not, then we should not be sending Location at all, for the same reasons
given for changing the name.  We want the dumb clients to present the
response message to the user.

>   If both headers are present in the response, the client SHOULD use
>   the 'Set-proxy' header only.


> 1.2 306 Switch Proxy
>   The 306 response is generated by a proxy server to indicate that the
>   client or proxy should use the information in the accompanying 'Set-
>   proxy' header to choose a proxy for subsequent requests.
>   The 306 response code MUST be accompanied by the 'Set-proxy' response
>   header.  The client or proxy will parse the 'Set-proxy' header to
>   determine which proxy to use, how long to use it, and for which URLs
>   to use it.

I know there was a reason why you created another status code for this,
but it isn't present in the spec.  Right now there is no visible distinction
between 305 and 306 behavior, and thus no reason to have 306.  If there
is a reason, why can't the distinction be made within the Set-proxy field?

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

This should not say " or client" -- clients don't generate responses
(a proxy does because it is both a client and a server).  And it is not
just any redirection -- it is a proxy redirect.  And the body MUST be

>2.0 Headers
> 2.1 'Set-proxy' Response Header
>           The 'Set-proxy' header is defined as:
>           Set-proxy: "Set-proxy" ":" 1(
>                   action #(parameters)
>                   )
>           parameters = #( ( "scope" "=" scopePattern ) |
>                   ( proxyURI "=" URI ) |
>                   lifetime )
>           lifetime = ( "seconds"  "=" integer )
>                   | ( "hits"      "=" integer )
>           action =  ( "DIRECT"
>                   | "IPL"
>                   | "SET" )
>                   ) ";"
>           scopePattern = "*" | "-" | URIpattern
>   An example header:
>       Set-proxy: SET ; proxyURI = "http://proxy.me.com:8080/",
>           scope="http://", seconds=5

Yuck!  BNF disaster alert.

Please follow the usual HTTP syntax or you will repeat the same
mistake made by Set-Cookie!  In other words

    Set-proxy  = ( "SET" proxy-URI [ ";" proxy-scope ] [ ";" proxy-life ] )
               | ( "IPL" [ proxy-URI ] )
               | "DIRECT"                              ; case-sensitive?

    proxy-URI    =  <"> absoluteURI <">

    proxy-scope  =  "scope" "=" scopePattern

    scopePattern =  "*" | "-" | ( <"> URIpattern <"> )

    proxy-life   =  ( "secs" "=" delta-seconds )
                 |  ( "hits" "=" 1*DIGIT )


    Set-proxy: SET "http://proxy.me.com:8080/"; scope="http://"; secs=5
    Set-proxy: IPL "http://config.me.com/"
    Set-proxy: DIRECT

Note that I eliminated "proxyURI" and changed "seconds" to "secs" because
the extra characters were unnecessary and less readable.  Also, any param
with a required value should never be sent.

>    Otherwise, the URL is compared with the scope after it is:
>   *   truncated to the length of the scope
>   *   domain names are set in reverse order.

That must be the wrong order.  I think it is a bad idea anyway and urge
you to either choose a special domain-matching character for the pattern
or just allow full regular expressions.

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

This makes no sense.  First, a proxy is a client.  Second, it just
received the 305 or 306 response, so obviously the server it is talking
to supports the 305 and 306 responses.  I have a feeling that this has
something to do with chaining proxies, but you need to spell it out.
In other words, list the cases where 305 and/or 306 responses should be
ignored even though they look "real", and why.

Given the lack of deployed HTTP/1.1 proxies, you might as well just rely
on the HTTP-version of the 305 or 306 response for distinguishing between
"real" and accidentally forwarded responses.

>   * Both the 305 and 306 response codes are HOP by HOP.  A proxy server
>     MUST not forward a 305 or 306 respose code (unless it generated the
>     306).

"forward" and "generated" do not overlap.

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

origin server.  These requirements beg for explanation.

>   * A proxy server MUST NOT generate a 305 response.

All proxies are servers.

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

All proxies are clients.  Explain why this requirement is needed.

BTW, it makes no sense to have all these extra requirements at the
bottom of your spec, since they often contradict the actual definitions
given above.  Put the requirements where the definitions are given.

>   * A client or proxy MAY maintain state and allow a lifetime to extend
>     beyond a session or restart.

Implementation detail (i.e., none of our business)

>   * Since HTTP/1.0 proxies may unknowingly forward a 305 or 306
>     response code that was generated maliciously or in good faith, the
>     client must attempt to ascertain if the proxy with which it is
>     directly communicating is HTTP/1.1 and if it supports the 'Set-
>     proxy' header.  To determine this, the client or proxy should use
>     the OPTIONS method to make a request check for this feature.

No, it shouldn't.  That is far too much overhead given the lack of
deployed implementations.

Received on Sunday, 15 June 1997 19:54:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC