Complete.Org: Mailing Lists: Archives: gopher: August 2008:
[gopher] Re: Item Type Suggestions
Home

[gopher] Re: Item Type Suggestions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Item Type Suggestions
From: nunojsilva@xxxxxxxxxx (Nuno J. Silva)
Date: Mon, 04 Aug 2008 16:58:26 +0100
Reply-to: gopher@xxxxxxxxxxxx

Cameron Kaiser <spectre@xxxxxxxxxxxx> writes:

>> Gopher+ or mime-at-the-end-of-the-menu-entry have both the same problem,
>> when you have an url, it's not possible to say what's the document type.
>
> And that's why I think this is ultimately doomed to fail. Part of what
> makes the itemtype so useful is because the behaviour for any given URL is
> totally known in advance. This makes client support a snap. So, short of
> a way to embed either an extended itemtype or a MIME type in the URL, this
> is probably going to wind up an academic exercise.
>
> W/r/t an earlier post I made, I did play around with various Overbite
> internal URL schemes for menus like this, but none were particularly
> satisfactory and having overbite:// URLs actually just fractionates the
> user community by having a non-interoperable URL format.

We already have an URL scheme which supports mime (the gopher+ views),
but that does not work with old clients:


quoting rfc1738:

>    A Gopher URL takes the form:
>
>       gopher://<host>:<port>/<gopher-path>
>
>    where <gopher-path> is one of
>
>        <gophertype><selector>
>        <gophertype><selector>%09<search>
>        <gophertype><selector>%09<search>%09<gopher+_string>


An url for a jpeg image made available as gophertype 9 with gopher+
would be (e.g., if the language is set as En_Us):

gopher://server/9blablabla%09%09+image/jpeg%20En_Us

But this needs some magic to work - the client has to remove the extra
tab, as there's no search string, because the server does not expect the
search field to be sent when it is empty.

Using gopher://server/9blablabla%09+image/jpeg%20En_Us works with lynx,
as it sends everything that's after the gophertype character and the end
of the URL.

NCSA Mosaic works too (you need to encode + as %2B).

On the other hand, conkeror and firefox (gecko engine) refuse to
retrieve the page, conkeror says nothing, and firefox raises an alert
messagebox saying it's an invalid URL, if I feed them a (non-rfc)
gopher+ URL.

Firefox with floodgap will work, but only if + is not encoded as %2B.

Now I just need to test this in some gopher+ clients...

If no issue is discovered, we could consider extending the standard to
allow (or better, enforce)

<gopher-path> = <gophertype><selector>%09<gopher+_string>

when the search string is empty.


-- 
Nuno J. Silva (aka njsg)
LEIC student at Instituto Superior Técnico
Lisbon, Portugal
Homepage: http://njsg.no.sapo.pt/
Gopherspace: gopher://sdf-eu.org/11/users/njsg
Registered Linux User #402207 - http://counter.li.org

-=-=-
``Research is what I'm doing, when I don't know what I'm doing.''
 -- von Braun




[Prev in Thread] Current Thread [Next in Thread]