[CTG] Draft 2008-11-07 / HTTPS link rewriting

a)	no-transform

Section 4.2.8.2 states:

	"Servers can prevent users from exercising 
	this choice by applying a Cache-Control: 
	no-transform directive."

This is inexact: a no-transform directive exactly
means that the response sent by the server must
not be modified. It has no bearing on the SSL/TLS
setup. It does not apply to previous HTTP exchanges
that might have led to https URL rewriting. In other
words, it is not the right mechanism to prevent
breaking a secure connection, or to signal a refusal
to handle point-to-point connections instead of
end-to-end ones -- except by widely stretching its
signification outside the specifications of RFC2616.


b)	Connection setup

This is something that has been already stated by 
several commentators: a response with the 
cache-control directive comes too late. By that
time, the secure connection is already interrupted
at the proxy level. Consider the following example:
1. Client accesses a page with a list of links (e.g.
from a web directory), one of them is an https URL.
2. The page gets transcoded, the https URL rewritten.
3. Client access rewritten URL.
4. Server gets rewritten https request and responds.

At (4), a no-transform directive will only ensure
that the content will not get transformed further.
If the page only contains relative URL, there is 
a possibility that the exchange may continue over
the broken secure connection, as the base URL on
the client side may be taken as the rewritten URL.
At this stage, there is no guarantee that the
connection may actually be secure, even for 
further exchanges specifying no-transform. The 
most probable behaviour of a server under these
circumstances is to return the code 403.


c)	Signalling with the server

The correct approach is to enable the server to
distinguish whether the secure connection is 
end-to-end or point-to-point. Somebody familiar
with the details of SSL/TLS may suggest something
at this level.

Otherwise, the necessity of including a reliable,
mandatory marker of transcoder presence in the HTTP 
header is once again evident.


E.Casais

Received on Tuesday, 11 November 2008 09:38:09 UTC