Subject: Same resource exposed over HTTP and HTTPS

From: Nathan <[email-masked]>
Date: Wed, 19 May 2010 15:36:59 +0100

Hi All,

I've hit on a scenario where we'd like to identify resource with http 
scheme URIs; where safe methods are exposed via standard HTTP, whereas 
unsafe methods (in this case PUT and DELETE) would be exposed via HTTPS.

I'm entirely unsure how to approach this, can find little documentation 
on doing Upgrade; and am very unsure what it means to PUT to https://.. 
and GET from http://.

The HTTP spec specifies "The PUT method requests that the enclosed 
entity be stored at the supplied request-target." and under p1 messaging 
4.2 "The exact resource identified by an Internet request is determined 
by examining both the request-target and the Host header field."

The above would lead me to believe that in both an http and https 
request (when using the 'path-absolute') that the resource identified in 
both cases is a scheme-less concatenation of host & 'path-absolute'. 
However when an the request-target is an absolute-URI then..? (do we 
chop the schemes off to get the resource identified?)

As you can see, in need of some clarification,

Best,

Nathan

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 19 May 2010 21:36:26 +0200

> unsafe methods (in this case PUT and DELETE) would be exposed via HTTPS.

Content-Location can be used to hint about this. If both http and https
respond with the same https content location then clients will have a
hint that they are the same and also a hint that this location should be
used when updating the resource.

> on doing Upgrade; and am very unsure what it means to PUT to https://.. 

Upgrade isn't used much if at all. Everyone seems quite satisfied with
using explicit https.

Upgrade can be compared to STARTTLS in other protocols if you are
familiar with that.

> by examining both the request-target and the Host header field."

Right. There is an unintentional gap there. http != https, but the above
fails to account for that.

Regards
Henrik

---

From: Nathan <[email-masked]>
Date: Wed, 19 May 2010 20:46:11 +0100

> used when updating the resource.

Nice answer, especially as I my follow up question (dependant on 
response) was going to be "and how would one hint or assert that HTTPS 
should be used for updates" - but you've covered that too!

> fails to account for that.

Could that be clarified with a note or suchlike in HTTPbis?

Many thanks,

Nathan

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 19 May 2010 21:55:25 +0200

should we cover this gap?

Probably should include something about the port which the request was
received on here, as is done by most known server implementations.

---

From: Nathan <[email-masked]>
Date: Thu, 20 May 2010 01:37:17 +0100

> used when updating the resource.

I appear to have hit a 'feature' that I've never seen before, and isn't 
documented anywhere in HTTPbis (from what I can see).

Short version in apache 2.2.8 is now sending me back the following:

   Content-Location: webr3.rdf, https://open.gs/users/webr3.rdf

Haven't done anything particularly special to produce this, all I've 
done is enable mod_cern_meta and add the following to a meta file:

   Content-Location: https://open.gs/users/webr3.rdf

The obvious question then, apache / mod_cern_meta bug - or something 
HTTP related.

Best,

Nathan

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 19 May 2010 20:12:18 -0500

>   Content-Location: webr3.rdf, https://open.gs/users/webr3.rdf

Seems entirely off topic for this list ([email-masked] is happy to entertain
such puzzles) but this seems consistent with cern_meta module adding a header, e.g.
you are looking at two header values merged, the first being webr3.rdf.

---

From: Nathan <[email-masked]>
Date: Thu, 20 May 2010 02:17:31 +0100

> you are looking at two header values merged, the first being webr3.rdf.

I realized I was a little unclear after sending..

Is the aforementioned a valid value for the Content-Location header, as 
in, can Content-Location have multiple comma separated values.

Haven't ever seen this before, and didn't note anything mentioning it here:
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-09#section-5.7

Please do confirm if the multiple values are allowed, if so then it's 
perfect tbh, ideal even :)

Best,

Nathan

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 19 May 2010 20:20:51 -0500

> perfect tbh, ideal even :)

99% certain it's not a good thing, but anyone employing a proper parser is
going to find the first or last value given (most likely the first, and the
rest will all report this specific configuration as bugged).

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 20 May 2010 03:25:06 +0200

> in, can Content-Location have multiple comma separated values.

No, Content-Location is a single-valued header.

> http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-09#section-5.7

All multi-valued headers in HTTPbis have list syntax, indicating in the
BNF that more than one value may be provided.

Regards
Henrik

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 May 2010 09:28:06 +0800

> 99% certain it's not a good thing, but anyone employing a proper parser
> is going to find the first or last value given (most likely the first, and
> the rest will all report this specific configuration as bugged).

Well, maybe.  A comma is a valid URI character, so you might find that a parser takes the comma to be part of the value.

Content-Location   = "Content-Location" ":" OWS Content-Location-v
Content-Location-v = absolute-URI / partial-URI
partial-URI   = relative-part [ "?" query ]

---

From: Nathan <[email-masked]>
Date: Thu, 20 May 2010 02:29:30 +0100

> No, Content-Location is a single-valued header.

thanks for the confirm - I'll submit a bug over on the apache list.

> BNF that more than one value may be provided.

noted that Accept-Language is marked as:

      Accept-Language   = "Accept-Language" ":" OWS
                         Accept-Language-v
      Accept-Language-v =
                         1#( language-range [ OWS ";" OWS "q=" qvalue ] )

Perhaps Content-Location could be made clear in the same way?

      Content-Location   = "Content-Location" ":" OWS
                        Content-Location-v
      Content-Location-v =
                        1#( absolute-URI / partial-URI )

rather than the current:

      Content-Location   = "Content-Location" ":" OWS
                        Content-Location-v
      Content-Location-v =
                        absolute-URI / partial-URI

Best,

Nathan

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 May 2010 09:51:29 +0800

>                         1#( absolute-URI / partial-URI )

That would be changing its definition, not clarifying its meaning.

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 20 May 2010 04:36:20 +0200

> Perhaps Content-Location could be made clear in the same way?

The specs assumes that each resource only have one original/primary URI,
with any other URIs referencing the same resource being aliases.

Changing Content-Location to be a multi-valued directive is not an
option within HTTP/1.x.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 May 2010 16:15:19 +0200

> received on here, as is done by most known server implementations.

Yes. This is a bug.

It's *related* to issue 196 which defines the Effective Request URI 
(where the proposal already takes http vs https into account). Of course 
the "identified/addressed resource" and the "effective request URI" 
definitions need to be consistent.

Now ticket 209 (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/209>)

Best regards, Julian