Re: RFC: proxy conventions
It was thus said that the Great Cameron Kaiser once stated:
> I perceive need for a convention around proxies (more than just SOCKS,
> especially for those clients that don't speak SOCKS), and preferably in a way
> that appears transparent to limited or historical clients (like Squid's gopher
> support, the server would do the work of translation). This means having to
> embed the hostname in the selector the client sends, e.g., the client requests
> from proxy.host the selector
>
> @gopher.floodgap.com/
>
> which would respond with Floodgap's main menu, but parsed so that the proxy is
> the server name, and selectors have the host prepended, e.g.,
>
> 1Example<TAB>@gopher.floodgap.com/example<TAB>proxy.host<TAB>70
>
> The client then requests
>
> @gopher.floodgap.com/example
>
Okay, just so I understand this a bit---a client behind the proxy would
send
@gopher.conman.org/
Then the proxy would request "" from gopher.conman.org and rewrite the page
iThank you. gopher.conman.org 70
i -- The Management gopher.conman.org 70
i gopher.conman.org 70
0About the server About:Server gopher.conman.org 70
0About the author About:Me gopher.conman.org 70
1Gopher Server Source Code Gopher:Src: gopher.conman.org 70
1Gopher Server Extensions Source Code Gopher:Ext: gopher.conman.org 70
to read (just a partial example here):
iThank you. @gopher.conman.org/ proxy.test 70
i -- The Management @gopher.conman.org/ proxy.test 70
i @gopher.conman.org proxy.test 70
0About the server @gopher.conman.org/About:Server proxy.test 70
0About the author @gopher.conman.org/About:Me proxy.test 70
1Gopher Server Source Code @gopher.conman.org/Gopher:Src: proxy.test 70
1Gopher Server Extensions Source Code @gopher.conman.org/Gopher:Ext: proxy.test 70
> from proxy.host, and so forth. I am not aware of selectors starting with a bare
> '@', though those are potentially legal (they'd have to be so that a client
> that's too smart for this idea doesn't reject the selector as bogus), so it's
> worth talking about.
I don't see an issue here. RFC-1436 shows that any character in the ASCII
range other than TAB, CR, LF and NUL are legal for the selector. I'm not
aware of any selectors that include control characters, but as long as a
client doesn't attempt to parse the selector and pass it along as-is, it
should be fine.
Then again, on several of my gopher pages I have to remind people that
selectors are opaque (RFC-1436, Introduction) and and the string should mean
nothing (RFC-1426, Section 2), because too many clients were adding an
initial '/' to selectors on my server (although that issue appears to be
slowly going away).
Even if a selector on a gopher server somewhere started with a '@', how can
it be an issue. A menu item like:
0Silly Example @ gopher.example.com 70
would be translated as:
0Silly Example @gopher.example.com/@ proxy.test 70
The client wouldn't care. The proxy is contacting a non-proxy, right? Or
are you worried about something like:
0Blowup @proxy.test/@proxy.test/ proxy.test 70
That, I can see as being a problem.
Gopher space isn't that big---it would probably be possible to search all
of it to see if any selectors start with '@'. But then you would have to
potentially deal with malicious links like the above.
-spc
Reply to: