[gopher] Correct error handling

[Damien Carol]

My crawler use this algorithm for Menu :

1 ) just download the response as binary.

2) If the response is small size => parse as Menu with '3' node => ERROR

3) else it's OK

I think the way floodgap manage non existant path is good. (GOGOPH Server
do the same)

2 importants things
=> '3' node MUST be present ONLY in response menu after an error.
=> if the size of response is small, client SHOULD try to parse response as
Menu to check '3' error nodes

Tell your opinions all !

2012/5/11 Kim Holviala <kim at holviala.com>

> On Thu, 10 May 2012, 06:01:25 EEST, Driedfruit <driedfruit at mindloop.net>
> wrote:
>
> > It seems to me, that servers either return errors via gopher menus,
> > either as plain-text. Is that behavior correct?
> >
> > gopher://floodgap.com/0/non-existant-path
> > gopher://floodgap.com/1/non-existant-path
> >
> > Plain-text files couldn't be parsed as gopher menus and vice versa, so
> > in either case the resulting output is flawed. Yet the response for the
> > 2 queries above is the same.
> >
> > So what's the deal here?
>
> The server doesn't know what filetype the client is requesting (it's not
> part of the request string). Gophernicus tries to guess, sometimes
> correctly, while most other servers won't even try (which really isn't any
> worse, just different).
>
> Gopher errors are just broken, plain and simple.
>
> - Kim
>
>
>
> _______________________________________________
> Gopher-Project mailing list
> Gopher-Project at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>



-- 
Damien CAROL
gopher://dams.zapto.org/1/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120511/6ef65166/attachment.html>