Subject: informal Last Call on draft-reschke-http-status-308-02

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 12:51:33 +0100

Hi,

I just submitted a new revision of draft-reschke-http-status-308 - see 
below (HTML version at 
<http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-02.html>).

At this point, I'd like to solicit additional feedback before I submit 
this to the IESG (which I plan to do in two weeks from now).

With respect to the venue: this isn't an HTTPbis WG deliverable due to 
our constrained charter. It *could* be an Applications Area WG 
deliverable; however, in a similar case 
(draft-nottingham-http-new-status, just out of IETF LC) we decided not 
to do this. Feedback on this appreciated as well...

Best regards, Julian

-------- Original Message --------
Subject: I-D Action: draft-reschke-http-status-308-02.txt
Date: Sat, 14 Jan 2012 02:55:23 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : The Hypertext Transfer Protocol (HTTP) Status Code 
308 (Permanent Redirect)
	Author(s)       : Julian F. Reschke
	Filename        : draft-reschke-http-status-308-02.txt
	Pages           : 7
	Date            : 2012-01-14

    This document specifies the additional HyperText Transfer Protocol
    (HTTP) Status Code 308 (Permanent Redirect).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 14 Jan 2012 15:44:08 +0200

Hello,

Hasn't HTTPbis WG considered incorporating this into httpbis-p2 draft?
 Is this a question of "experimentality" of the proposed extension (as
Intended status is Experimental)?

Otherwise, having quickly reviewed the document, I am fine with its publication.

Mykyta Yevstifeyev

2012/1/14 Julian Reschke <[email-masked]>:
> Hi,
>
> I just submitted a new revision of draft-reschke-http-status-308 - see below
> (HTML version at
> At this point, I'd like to solicit additional feedback before I submit this
> to the IESG (which I plan to do in two weeks from now).
>
> With respect to the venue: this isn't an HTTPbis WG deliverable due to our
> constrained charter. It *could* be an Applications Area WG deliverable;
> however, in a similar case (draft-nottingham-http-new-status, just out of
> IETF LC) we decided not to do this. Feedback on this appreciated as well...
>
> Best regards, Julian
>
>
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 15:29:14 +0100

> Hasn't HTTPbis WG considered incorporating this into httpbis-p2 draft?

The charter of the HTTPbis WG currently does not allow adding new features.

> Intended status is Experimental)?

That as well.

> Otherwise, having quickly reviewed the document, I am fine with its publication.

Thanks.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Jan 2012 16:18:40 +0100

>this to the IESG (which I plan to do in two weeks from now).

Your HTML example has a bad <title> and doesn't even validate, never
minding the lack of character encoding information in the sample re-
sponse. I would suggest something like

  HTTP/1.1 308 Permanent Redirect
  Content-Type: text/html;charset=utf-8
  Location: http://example.com/new

  ...
  <meta http-equiv='refresh' content='0; url=http://example.com/new'>
  ...

which would avoid the stylistic problems in addition to being much
shorter.

In the IANA Considerations I think it is better to say something like
"This document adds such and such to registry so and so" or whatever,
rather than the imperative, as the "shall" will be weird after IANA
added it, and not having to change such text is better than having to.

The RFC3986 reference seems non-normative to me.

Back when someone at the IETF secretariat checked internet drafts prior
to posting them, I had one rejected because the Abstract was too short.
Your Abstract is much shorter, it might be a good idea to add a sentence
what the status code is for.

I think you need a better term for "permanent URI". How about simply re-
moving the "permanent" and possibly adding "new" to the second instance?

The fallback requirement

  Unless the request method was HEAD, the representation of the response
  SHOULD contain a short hypertext note with a hyperlink to the new
  URI(s), since most user agents do not understand the 308 status code
  yet. Therefore, the note SHOULD contain the information necessary for
  a user to repeat the original request on the new URI.

strikes me as a bad idea. It's a transient problem so it should be con-
ditioned and how widely supported this is, and it's only useful if you
have some HTML implementation on the other end or an interactive user; a
web service not meant for interactive use where you can be sure that the
code is supported, because, say, you control the client, is unaffected,
and if you add that as another exception you basically end up saying you
can do this so your site works better with legacy clients in some situ-
ations and making your site work good is probably a good idea, so I'd
prefer just saying that. I don't really want to ponder whether I should
send this hypertext response in response to an OPTIONS request in 2015,
just because your specification says I should.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 16:27:58 +0100

On 2012-01-14 16:18, Bjoern Hoehrmann wrote:
> Your HTML example has a bad<title>  and doesn't even validate, never

- what's the problem with the title?
- why do I need to specify encoding? It's all US-ASCII
- validator.nu says it's happy once I had the HTML4 strict doctype; 
would that work for you?

> added it, and not having to change such text is better than having to.

The RFC Editor rewrites this part upon publication.

> The RFC3986 reference seems non-normative to me.

May be.

> what the status code is for.

I'll monitor what happens with draft-nottingham-http-new-status, just 
out of LC which looks similar to me. (It also has "invalid" HTML, why 
didn't you complain? :-)

> moving the "permanent" and possibly adding "new" to the second instance?

I'd prefer to use language consistent with RFC 2616.

> just because your specification says I should.

Again, this is consistent with RFC 2616 and HTTPbis (for now).

We may want to tune the text in HTTPbis (please follow up over there), 
in which case I'll apply the same changes to the spec for 308.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Jan 2012 16:50:20 +0100

>in which case I'll apply the same changes to the spec for 308.

Here we are.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Jan 2012 16:48:59 +0100

>- what's the problem with the title?

When the redirect target disappears but the redirect does not, then you
might end up with "Permanent Redirect" as title in search results which
looks very broken and is uninformative. A better title would be "Moved 
to <new location>".

>- why do I need to specify encoding? It's all US-ASCII

Because RFC 2854 says it's strongly recommended to use the parameter.

>- validator.nu says it's happy once I had the HTML4 strict doctype; 

I can live with that.

>The RFC Editor rewrites this part upon publication.

Or forgets to do so and you forget to check and we end up with bad text.

>I'd prefer to use language consistent with RFC 2616.

Well, in RFC 2616 it makes a little bit more sense as there you have the
contrast with temporary addresses, but "permanent" is the condition that
the resource has a different address than the current one, but that does
not mean the new address will be "permanent". But oh well, your argument
is good enough.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 16:54:14 +0100

On 2012-01-14 16:48, Bjoern Hoehrmann wrote:
> to<new location>".

3xx responses never should show up in search results. Or am I missing 
something?

> Because RFC 2854 says it's strongly recommended to use the parameter.

Well, it's a silly recommendation in this case. And it's NOT UPPERCASE!

> Or forgets to do so and you forget to check and we end up with bad text.

Please trust my AUTH48 skills.

> not mean the new address will be "permanent". But oh well, your argument

Again, I'm with you in that we may want to tune the 3xx descriptions. 
But we should be consistent in what we change.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Jan 2012 17:51:17 +0100

>3xx responses never should show up in search results. Or am I missing 

When all of http://schnitzelmitkartoffelsalat.example/ redirects to some
address the search engine cannot connect to, and someone searches for,
say, "schnitzelmitkartoffelsalat.example", the search engine might still
list the site in the results, and might link the proper address instead
of the redirect target which it cannot resolve (reasons include that the
user might be able to connect to sites the search engine can't connect
to).

>Well, it's a silly recommendation in this case. And it's NOT UPPERCASE!

If you really want to argue that the example is better when it does not
declare the character encoding without very clearly indicating that the
declaration has been elided because it's "all US-ASCII" ... Do you still
keep Internet Explorer 6 around? It should be possible to make an ex-
ample that does not redirect to where you think it would, but I would
have to set up a virtual machine for testing and there kinda would be no
point if you don't have the right browser to try it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 18:15:30 +0100

> declaration has been elided because it's "all US-ASCII" ... Do you still

I think it doesn't matter at all; but I'll change it.

> point if you don't have the right browser to try it.

Could you elaborate about what this has to do with IE6?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 14 Jan 2012 18:49:30 +0100

>Could you elaborate about what this has to do with IE6?

Without explicit declarations browsers will auto-detect an encoding and
in case of Internet Explorer 6 that means that some US-ASCII documents
without encoding declarations are treated as UTF-7 encoded documents, so
if you try to redirect to something like /Bj+APY-rn/ IE might end up on
/Björn/ even though "Bj+APY-rn" is "all US-ASCII". That problem was not
specific to Internet Explorer 6, but it's the cheapest target. Avoiding
such misdetection is important for security reasons, so responses with-
out encoding declarations are likely to be or to become security risks.
It's like seeing `"SELECT * FROM table WHERE column = '$user_input';"`
in a PHP tutorial.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jan 2012 19:17:20 +0100

> It's like seeing `"SELECT * FROM table WHERE column = '$user_input';"`

Ack. Thanks. "charset=" added.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Jan 2012 18:57:39 +0100

>> in which case I'll apply the same changes to the spec for 308.

Indeed; I forgot that I was cross-posting :-)

I have raised this point as 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/332>.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Jan 2012 19:18:03 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/332>.

In the meantime I made a small change to HTTPbis P2, which still called 
307 "a new status code". The advice on the response body is now the same 
as for 302.

See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1508>.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2012 10:56:30 +1100

On 25/01/2012, at 5:18 AM, Julian Reschke wrote:

> In the meantime I made a small change to HTTPbis P2, which still called 307 "a new status code". The advice on the response body is now the same as for 302.
> 

+1, I think that's a resolution to 322.

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 01:07:01 +0100

On 2012-01-25 00:56, Mark Nottingham wrote:
>> See<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1508>.
>>
>> Best regards, Julian
>>
>

The question remains whether we should relax more of the SHOULD-level 
requirements on response payloads. At least some of them seem fishy (not 
necessarily the 3xx ones). Will send separate mail later this week.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 20:30:07 +0100

> necessarily the 3xx ones). Will send separate mail later this week.

Here we go; excerpts from P2 Section 7:

7.2.2.  201 Created

    The request has been fulfilled and has resulted in a new resource
    being created.  The newly created resource can be referenced by the
    URI(s) returned in the payload of the response, with the most
    specific URI for the resource given by a Location header field.  The
    response SHOULD include a payload containing a list of resource
    characteristics and location(s) from which the user or user agent can
    choose the one most appropriate.  ...

This seems fishy. In particular it makes little sense for PUT->2

    ... The payload format is specified by
    the media type given in the Content-Type header field.

Some status codes descriptions state this, some do not. It is always 
true, however. Maybe just say this once at the beginning of Section 7?

    ...

7.2.3.  202 Accepted

    The request has been accepted for processing, but the processing has
    not been completed.  The request might or might not eventually be
    acted upon, as it might be disallowed when processing actually takes
    place.  There is no facility for re-sending a status code from an
    asynchronous operation such as this.

    The 202 response is intentionally non-committal.  Its purpose is to
    allow a server to accept a request for some other process (perhaps a
    batch-oriented process that is only run once per day) without
    requiring that the user agent's connection to the server persist
    until the process is completed.  The representation returned with
    this response SHOULD include an indication of the request's current
    status and either a pointer to a status monitor or some estimate of
    when the user can expect the request to be fulfilled.

This one makes sense...

    ...

7.3.1.  300 Multiple Choices

    The target resource has more than one representation, each with its
    own specific location, and agent-driven negotiation information
    (Section 5 of [Part3]) is being provided so that the user (or user
    agent) can select a preferred representation by redirecting its
    request to that location.

    Unless it was a HEAD request, the response SHOULD include a

This one makes sense.

    representation containing a list of representation metadata and
    location(s) from which the user or user agent can choose the one most
    appropriate.  The data format is specified by the media type given in
    the Content-Type header field.  Depending upon the format and the
    capabilities of the user agent, selection of the most appropriate
    choice MAY be performed automatically.  However, this specification
    does not define any standard for such automatic selection.

    If the server has a preferred choice of representation, it SHOULD
    include the specific URI for that representation in the Location
    field; user agents MAY use the Location field value for automatic
    redirection.

    Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
    determine freshness for 300 responses.

7.3.2.  301 Moved Permanently

    The target resource has been assigned a new permanent URI and any
    future references to this resource SHOULD use one of the returned
    URIs.  Clients with link editing capabilities ought to automatically
    re-link references to the effective request URI to one or more of the
    new references returned by the server, where possible.

    Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
    determine freshness for 301 responses.

    The new permanent URI SHOULD be given by the Location field in the
    response.  Unless the request method was HEAD, the representation of
    the response SHOULD contain a short hypertext note with a hyperlink
    to the new URI(s).

Björn says this is too strong; maybe demote to "ought to"? (The same 
applies to 302 and 307).

    ...

7.4.4.  403 Forbidden

    The server understood the request, but refuses to authorize it.
    Providing different user authentication credentials might be
    successful, but any credentials that were provided in the request are
    insufficient.  The request SHOULD NOT be repeated with the same
    credentials.

    If the request method was not HEAD and the server wishes to make
    public why the request has not been fulfilled, it SHOULD describe the
    reason for the refusal in the representation.  If the server does not
    wish to make this information available to the client, the status
    code 404 (Not Found) MAY be used instead.

This one seems ok to me.

    ...

7.4.7.  406 Not Acceptable

    The resource identified by the request is only capable of generating
    response representations which have content characteristics not
    acceptable according to the Accept and Accept-* header fields sent in
    the request (see Section 6 of [Part3]).

    Unless it was a HEAD request, the response SHOULD include a
    representation containing a list of available representation

Seems ok to me.

    characteristics and location(s) from which the user or user agent can
    choose the one most appropriate.  The data format is specified by the
    media type given in the Content-Type header field.  Depending upon
    the format and the capabilities of the user agent, selection of the
    most appropriate choice MAY be performed automatically.  However,
    this specification does not define any standard for such automatic
    selection.

       Note: HTTP/1.1 servers are allowed to return responses which are
       not acceptable according to the accept header fields sent in the
       request.  In some cases, this might even be preferable to sending
       a 406 response.  User agents are encouraged to inspect the header
       fields of an incoming response to determine if it is acceptable.

    If the response could be unacceptable, a user agent SHOULD
    temporarily stop receipt of more data and query the user for a
    decision on further actions.

    ...

7.4.10.  409 Conflict

    The request could not be completed due to a conflict with the current
    state of the resource.  This code is only allowed in situations where
    it is expected that the user might be able to resolve the conflict
    and resubmit the request.  The response body SHOULD include enough

"ought to"?

    information for the user to recognize the source of the conflict.
    Ideally, the response representation would include enough information
    for the user or user agent to fix the problem; however, that might
    not be possible and is not required.

    Conflicts are most likely to occur in response to a PUT request.  For
    example, if versioning were being used and the representation being
    PUT included changes to a resource which conflict with those made by
    an earlier (third-party) request, the server might use the 409
    response to indicate that it can't complete the request.  In this
    case, the response representation would likely contain a list of the
    differences between the two versions in a format defined by the
    response Content-Type.

    ...

7.4.19.  426 Upgrade Required

    The request can not be completed without a prior protocol upgrade.
    This response MUST include an Upgrade header field (Section 8.7 of
    [Part1]) specifying the required protocols.

    Example:

      HTTP/1.1 426 Upgrade Required
      Upgrade: HTTP/3.0
      Connection: Upgrade
      Content-Length: 53
      Content-Type: text/plain

      This service requires use of the HTTP/3.0 protocol.

    The server SHOULD include a message body in the 426 response which
    indicates in human readable form the reason for the error and
    describes any alternative courses which may be available to the user.

Seems ok to me.

7.5.  Server Error 5xx

    Response status codes beginning with the digit "5" indicate cases in
    which the server is aware that it has erred or is incapable of
    performing the request.  Except when responding to a HEAD request,
    the server SHOULD include a representation containing an explanation
    of the error situation, and whether it is a temporary or permanent
    condition.  User agents SHOULD display any included representation to
    the user.  These response codes are applicable to any request method.

Seems ok to me.

    ...

7.5.6.  505 HTTP Version Not Supported

    The server does not support, or refuses to support, the protocol
    version that was used in the request message.  The server is
    indicating that it is unable or unwilling to complete the request
    using the same major version as the client, as described in Section
    2.6 of [Part1], other than with this error message.  The response
    SHOULD contain a representation describing why that version is not
    supported and what other protocols are supported by that server.

This may not be needed given the text for 5xx.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Jan 2012 11:34:13 +1100

> This seems fishy. In particular it makes little sense for PUT->2

+1. Downgrade to prose?

> Some status codes descriptions state this, some do not. It is always true, however. Maybe just say this once at the beginning of Section 7?

+1 

> Björn says this is too strong; maybe demote to "ought to"? (The same applies to 302 and 307).

Assuming you mean the second SHOULD, +1

>   and resubmit the request.  The response body SHOULD include enough

-1

I think this information is important.

> This may not be needed given the text for 5xx.

Doesn't hut to be specific, though. - 0.5

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 26 Jan 2012 03:22:59 +0100

>Björn says this is too strong; maybe demote to "ought to"? (The same 

I think this should say something along the lines of "if the response
body is rendered by an interactive user agent then the response body
could be a hypertext document containing a link so users of old clients
that do not support the status code as specified can easily follow the
redirect". I think the "unless HEAD" is too broad since it would apply
to cases where the hypertext document would be of no use (like for an
OPTIONS response) and this is not required for interoperation among im-
plementations and does not deal with "harm", so the use of RFC 2119
"SHOULD" is wrong.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Jan 2012 13:26:58 +1100

> plementations and does not deal with "harm", so the use of RFC 2119

Are you suggesting that the server try to figure out whether the client is an "interactive user agent"?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 26 Jan 2012 03:35:08 +0100

>is an "interactive user agent"?

No, I just don't want any such requirement or suggestion to apply when
it is fairly clear that there is no user agent on the other end.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 17:47:16 +0100

>> Some status codes descriptions state this, some do not. It is always true, however. Maybe just say this once at the beginning of Section 7?

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1515>

   "For most status codes the response can carry a payload, in which case
    a Content-Type header field indicates the payload's media type
    (Section 6.8 of [Part3])."

Hopefully that's precise enough...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 18:20:32 +0100

>> This seems fishy. In particular it makes little sense for PUT->2

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1516>

(s/SHOULD/can/)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jan 2012 18:30:25 +0100

> plementations and does not deal with "harm", so the use of RFC 2119

Can we simply say:

"A response payload can contain a short hypertext note with a hyperlink 
to the new URI(s)."

?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Jan 2012 11:46:11 +0100

> "A response payload can contain a short hypertext note with a hyperlink

I see no negative feedback and got one off-list "yes", so here's the 
proposed change:

<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/332/332.diff>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jan 2012 22:33:38 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/332/332.diff>

Seeing no objections -> 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1521>