Re: [gopher] Correct error handling

[Damien Carol <damien.carol@gmail.com>]

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@holviala.com>

On Thu, 10 May 2012, 06:01:25 EEST, Driedfruit <driedfruit@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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project

-- 
Damien CAROL
gopher://dams.zapto.org/1/
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project