On Tue, Nov 6, 2012 at 1:47 PM, Vijay K. Gurbani <[email protected]> wrote:
> On 11/06/2012 01:22 PM, Junchang(Jason) Wang wrote:
>
>> Last night, Richard and me together compared your script (simply
>> returned E_SYNTAX) and ours (worked correctly) line by line for at least
>> 10 minutes, and finally figured out there's a extra 's' in your script
>> which inured the problem.
>>
>
> Jason: Right, I discovered that later as well.
>
>
> I wonder whether it's reasonable that servers return error code
>> (say E_SYNTAX) PLUS some clues (say, a piece of the string that incurs
>> the problem). I think that benefits clients a lot.
>>
>
> That is always a good option, but the best place to put this would
> have been in definition of ErrorResourceEntity (c.f. Section 6.5.2
> of the ALTO protocol document). I think it is too late to add it
> now,
The ALTO protocol used to have a reason that was free-form text. Ted
Hardie suggested in his review that we drop this to avoid multi-language
issues (as Richard Yang pointed out). We then removed the reason field.
> but more importantly, I don't think we absolutely need this
> functionality. HTTP is rich enough to provide for richer error
> responses without us introducing mechanisms in ALTO.
>
> As Richard mentions, a more appropriate HTTP status code to return
> in this particular case would have been a 404, not 400. It is
> the R-URI that was the problem here.
>
> But there are other mechanisms to inform the client of the nature of the
> error without necessarily nailing it down in the ALTO protocol
> specification. A couple of that come to mind are:
>
> 1) Use a more descriptive Reason-Phrase. For instance, consider Test-
> JSON-ERR-1 from draft-gurbani-alto-interop-**cases-02. In that test
> case, the server returns a "400 Bad Request". There is nothing to
> stop the server returning "400 Mismatched braces in entity-body".
> The Reason-Phrase is there for consumption of humans, so the more
> descriptive it is, the better.
>
> 2) Use multi-part MIME. One part is the normal
> "application/alto-error+json" and the other part could be
> "text/plain" that describes the error in more detail.
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} /
> vijay.gurbani@alcatel-lucent.**com<[email protected]>
> Web: http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>
>
> ______________________________**_________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/**listinfo/alto<https://www.ietf.org/mailman/listinfo/alto>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
