Subject: [apps-discuss] 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: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.