[gopher] Correct error handling

[Damien Carol]

Yes, your solution is good.

Maybe we can check that every server and proxy handle error like this.

Now :

ERROR HANDLING
==============
1 ) Download the response as binary.

2) Try to parse as Menu => if Menu with first node as '3' error type =>
ERROR

3) else it's OK

2 importants things
=> A '3' error node MUST be at first place if the response is ERROR
=> A '3' node MUST be present ONLY in response menu after an error.

2012/5/11 Wolfgang Faust <wolfgangmcq at gmail.com>

>
>
> On Fri, May 11, 2012 at 7:59 AM, Damien Carol <damien.carol at gmail.com>wrote:
>
>> 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
>>
> What if the binary document is small? Or if the server sends a long error
> message with, say, a stack trace?
>
>>
>> 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 !
>>
>> I think that the client should attempt to parse it as a menu, and if the
> first item is a valid '3' itemtype, consider it an error.
>
>>
>> 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/
>>
>> _______________________________________________
>> Gopher-Project mailing list
>> Gopher-Project at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>>
>
>
>
> --
> 01010111 01101111 01101100 01100110
>
> _______________________________________________
> 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/fae61e5b/attachment.html>