[gopher] Re: Searches as defined by RFC1436
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
> The client sends the server the selector string, a tab, and the search
> string (words to search for).
> When I try this with Veronica-2 on floodgap, I get a "resource not
> found" error (actually, FF refuses to even process the query):
> However, this works fine in the following format:
> Is this a discrepancy between the RFC and how this particular search
> is implemented, or am I reading the RFC wrong?
It's not the RFC that's tripping you up, it's how Gopher URLs are encoded
in Firefox. To demonstrate,
% telnet gopher 70
Connected to helsinki.floodgap.com.
Escape character is '^]'.
1Floodgap Systems gopher root / gopher.floodgap.com 70
Firefox's handling is in fact contrary to RFC 4266, which says,
2.2. Specifying URLs for Gopher Search Engines
If the URL refers to a search to be submitted to a Gopher search
engine, the selector is followed by an encoded tab (%09) and the
search string. To submit a search to a Gopher search engine, the
Gopher client sends the <selector> string (after decoding), a tab,
and the search string to the Gopher server.
Nevertheless, this appears to have been abstracted from RFC 3986,
The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any). The query component is indicated by the first question
mark ("?") character and terminated by a number sign ("#") character
or by the end of the URI.
OverbiteFF accepts both syntaxes; the output of URLs
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- Remember, Windows is not a virus. Viruses actually do something. -----------