Re: [Filterproxy-devel] Re: New module for FilterProxy

[John F W. <way...@WP...>]

On Sun, 5 Aug 2001, Bob McElrath wrote:
> That's fine (see below on eval).  I want to go further than a diff
> though (for instance, also insert the name of the rule that made the
> change).

Although it's not necessary to use diff if you build up a list of changes
as Rewrite does its work.

> Done.  Now it loops over files in FilterProxy/, eval's them, and keeps
> going if the eval fails.  Looking for filter rules would be a bit
> harder, since you have to know the module exists, before you load it...
> (i.e. Compress isn't used now but you want to add it for some site...)

Well, I suppose this solution works.  Though if you eval, as opposed to
use, you're not going to do the import call that use does (unless you call
it yourself)

> Ok, so I started to outline how this would work, and I just can't get
> around the fact that we need to send *extra* data with the request.
> Whether we want to return the source or return highlighted source,
> framed or not, it's the same...the behavior isn't default, and we have
> to signal that.  And it must work for ANY url.
>
> Is there any other way to get data from the browser to the proxy than in
> the URI?  Can browsers handle a cookie for the proxy, or a cookie for
> all domains?

Nope.  The Cookie spec specifically requires two dots or more.  So it
won't send to .com, or to the whole internet.

> If the answer is no...the only *proper* way to do it is to write a whole
> lot of code along the lines of http://localhost:8888/Source.html?get=%%%

Ick.  I just can't be happy with that, it doesn't settle right with me...
Furthermore, I'm not even sure how to urlencode in javascript.

>
> Checking Netscape and Mozilla, It looks like multiple ? aren't a
> problem, but with multiple # the last one is stripped off.  (These
> aren't intended for servers anyway)  But adding the data at the end of
> the URI after a ? could easily run into the maximum URI-length problem.

I don't think we'll hit a max URI length problem.  I'm not sure there IS
such a maximum, but plenty of sites out there use HUGE query strings.

> Arg.  Yeah, but editing the config will require interaction with the
> core script too...

I'm not so leary of adding new rules that call the Source module, as I am
of actually writing this into the proxy itself.

> This mechanism requires a whole lot of code to be written...  Basically
> duplicating &handle_proxy, except storing the data, rather than feeding
> it to the client.  Ick.

Right.  I think we should avoid this.

Ok, I've just read the RFC for URI.  This is legal:

http://source/http://foobaretc/

I still see this as the most viable option for communicating a view-source
command.  To avoid masking a hostname on the local network named "source",
we could do the following, to further avoid masking a host:

http://view.source/http://foobaretc/