Michael, On 2013-05-29, at 12:58 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > ... > I have a stupid question. > What does it mean to have an interface identifier go through an HTTP proxy? > > Given that a proxy works by having the client send the entire URL on the > GET line, it means that my web browser would send something like: > > GET http://[fe80::a%25en1]/printers/laserwrite > Host: [fe80::a%25en1] > > to the proxy. Now, where is %en1 going to be interpreted? > On the proxy? How can the client have any idea what to send. > It can't mean anything on the client, because the entire URL > goes to the proxy.
You might be able to stretch things to allow a proxy for a locally-discovered device like a printer, e.g,, some sort of security policy at an organization. But in that case while the proxy might forward the link-local URI as-is, it would also need to ignore the zoneid and use ND or an "all interfaces" approach to forward the request to the device. > ... > We have an existing problem in CUPS at least, that the certificates > generated for the https do not have all the valid names, nor can they. Well, there *are* multi-domain certificates, but most people stick with self-signed or organization-signed certs. Longer term I want to add full SNI support - this mostly works for OS X already (we'll search for a matching cert in the system keychain) but needs more work on Linux. >>> All of this falls apart with link-local addresses and RFC 6874. >>> Because the client is required to remove the zoneid from the >>> outgoing request, the URIs it gets back from the server are no >>> longer "reachable". > > I think that part of the bug is the return of absolute URLs. I question > whether that is truly necessary.. Why aren't relative URLs (rooted at /) > useable? Because we have four URI schemes/protocols - http, https, ipp, and ipps - and multiple port numbers to deal with for printers. And right now there is no way to do a relative URI that just changes the scheme and/or port. > ... >>> What I propose is that we change the wording to allow the zoneid >>> in the Host header but not in the Request-URI. HTTP proxies >>> would be required to strip any zoneid information in the Host >>> header. HTTP servers would be required to ignore any zoneid >>> information for purposes of address validation but include it for >>> any absolute URIs to the server they generate. > > This seems nonsensical to me. > If the zoneid is not in the Request-URI, then how can the proxy do > anything with it? What address is in the Host: header that has a > meaningful zoneid? The reason for having proxies strip the zoneid is because the zoneid is only useful to the client - not to the proxy and not to the server. But I wasn't really considering the use of a proxy for local network access (above). The Host header contains the client's zoneid information and gets used in any URIs returned by the server (so that the client is able to access the server via those URIs without having to figure out what zoneid to use...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
