Re: Section on https

Roy, you are emphatic about much of this, but in fact I think you are 
right for some cases. In any event, I can't see us trying to get 
anything for the 1.0 document.

Tim BL


On Dec 4, 2003, at 14:23, Roy T. Fielding wrote:

>
>> We nuked this due to under-cookedness.  I'm sympathetic to Ian's 
>> point, so I've shaken & stirred the existing language slightly; I 
>> understand the date is very late, but if lots of TAG members write 
>> back and say "yes" maybe it could squeeze in:
>
> I didn't like it because it is just wrong.  Security policy can only be
> negotiated if you decide to manage it prior to making a request, which 
> is
> obviously a bad idea for a protocol that does not require security
> 99.999% of the time.

I am not sure what you mean here.  To start a connection with HTTP and 
then hand the TCP connection over to SSL always sounded an interesting 
way to me. Client and/or server might require it, and they might want 
it for various reasons.

>   It is therefore a better trade-off to separate
> the need-to-negotiate services from those that don't need it, and the
> only way to do that is by indicating the separation within the URI
> because the client needs to know *before* the first request.

One could argue that privacy and security and authentication should all 
be visible up front - but it means you can't change them and it means 
that the number of scheme names grows as the product.

>   The
> next question is then whether we want these services on the same
> port as the unsecured protocol, and the answer is generally "no" since
> that interferes with the ability to pipe-filter servers.  Finally,
> would we want the same services to be available via both http and
> https?  An emphatic "no" to that one, since it results in security
> holes.

On the contrary.  One might want user choice. The same service might be 
available on HTTP to those inside a firewall, but by HTTPS by those 
outside. One might want to be able to access the same images while 
browsing a catalog using HTTP as one does later when order some items 
with a secure connection.  A browser might want to go back and 
re-access things it has in cache over a secure connection for security 
(might, might not) but giving the secure one separate URIs is a kludge.

> We could argue that the "s" bit doesn't belong in the scheme,
> but since it defines a separate resource space the result would be
> equivalent to a separate scheme regardless of where it appears in
> the URI.

I would argue that the s bit one of many.

> As a result, the "https" scheme or something equivalent to it is and
> will always be necessary, and the resources identified by it have no
> connection whatsoever to the resources identified by the "http" scheme
> even if you have two URI that only differ in the "s".

I think I have shown practical examples in which this is not the case.

> Thus, the example is incorrect.

... which would leave cases when the example is fine.

> ....Roy

Received on Thursday, 4 December 2003 16:45:49 UTC