W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

RE: ACTION-902 (Reprise) Summarise and prepare proposed resolutions on HTTPS link rewriting.

From: Sullivan, Bryan <BS3131@att.com>
Date: Thu, 19 Mar 2009 09:49:07 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD0D78566A@BD01MSXMB015.US.Cingular.Net>
To: "Robert Finean" <Rob.Finean@openwave.com>
Cc: "Public MWBP" <public-bpwg@w3.org>
Hi Rob,
The concern is based upon the a domain-based approach involving the assignment of subdomains through DNS. If the set of domains to be rewritten is fairly static (e.g. only a few changes per day) then DNS can handle it, although it is an overhead on someone (or some system) to update DNS records and for the records to be distributed through the DNS system as requested.

An alternate approach is to use URL path tokens associated with the specific domains being rewritten, e.g. for "http://origdomain.com/path" one of the methods:
"http://ctproxy.com/rewriter/f8w7yf87ch/path" (where "f8w7yf87ch" is some token that the CT proxy assigns to the original domain)
"http://ctproxy.com/rewriter?origuri=http://origdomain.com/path" (with URI escaping as needed)

I'm sure there are many more such approaches.

These approaches do not impact DNS, and thus are better suited for cases in which the CT proxy is not pre-configured to support rewriting for an arbitrary web site ala this sequence:
(1) User browses to a site through the CT proxy
(2) The site returns content with links to other sites, which are rewritten by the CT proxy to ensure the requests flow through it

The sites in (2) may not already be setup for link rewriting at the CT proxy. It would be a very significant overhead on the DNS system to issue DNS update requests for such dynamically configured sites.

Is that clearer?

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Robert Finean [mailto:Rob.Finean@openwave.com] 
Sent: Thursday, March 19, 2009 7:26 AM
To: Sullivan, Bryan
Cc: Public MWBP
Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed resolutions on HTTPS link rewriting.

Hi Bryan,

I don't understand this rationale:

2) PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
transformation is permitted, providing that content domain origin
distinctions are preserved by the proxy.
-1 : Rationale is that scalability and basic ability to dynamically
extend the link rewriting support to new sites will prevent a subdomain
approach from being feasible. Link rewriters that I have worked with use
URL path tokens associated with the original URI, which is scalable
since there is no dependency upon DNS.

Can you explain please (maybe an example)?


Received on Thursday, 19 March 2009 16:49:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC