Subject: Re: [alto] Constraints results in E_SYNTAX

From: "Junchang(Jason) Wang" <[email-masked]>
Date: Tue, 6 Nov 2012 14:22:39 -0500

Dear Vijay,

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.

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.

Thanks.

--Jason

On Mon, Nov 5, 2012 at 11:54 PM, Y. Richard Yang <[email-masked]> wrote:

> Hi Vijay,
>
> On Mon, Nov 5, 2012 at 9:35 PM, Vijay Gurbani <[email-masked]>wrote:
>
>> Here is the request:
>> POST /endpoints/costs HTTP/1.1
>>
>
> costs -> cost according to spec?
>
> Richard
>
>
>> Accept: application/alto-endpointcost+json,application/alto-error+json
>> Content-Type: application/alto-endpointcostparams+json
>> Content-Length: 488
>>
>> {
>>    "constraints": ["le 5", "ge 4"],
>>    "cost-mode": "numerical",
>>    "cost-type": "routingcost",
>>    "endpoints": {
>>       "dsts": [
>>         "ipv4:10.0.0.0",
>>         "ipv4:15.0.0.0",
>>         "ipv4:192.168.11.0",
>>         "ipv4:192.168.10.0",
>>         "ipv4:128.0.0.0",
>>         "ipv4:130.0.0.0",
>>         "ipv4:0.0.0.0",
>>         "ipv4:132.0.0.0",
>>         "ipv4:135.0.0.0"
>>       ],
>>       "srcs": [
>>         "ipv4:10.0.0.0",
>>         "ipv4:192.168.11.0",
>>         "ipv4:192.168.10.0"
>>       ]
>>    }
>> }
>>
>> and response:
>> cat Test-ECS-3.txt | nc p4p-1.cs.yale.edu 6671
>> HTTP/1.1 400 Bad Request
>> Content-Length: 24
>> Content-Type: application/alto-error+json
>> Date: Tue, 06 Nov 2012 02:47:18 GMT
>>
>> {
>>         "code" : "E_SYNTAX"
>> }
>>
>
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 6 Nov 2012 15:14:41 -0500

Hi Jason,

On Tue, Nov 6, 2012 at 2:22 PM, Junchang(Jason) Wang <[email-masked]
> wrote:

> problem). I think that benefits clients a lot.
Adding a string then opens the issue of multi-language support, which can
become a problem.

Regarding the specific test case, I would imagine that a more specific
error is an error code indicating that the client has required a URL that
is not exposed by the Information Directory (due to a typo in the current
case). In the current spec, this is shown as a general ALTO code E_SYNTAX
and HTTP status code 400 (Bad Request). I can imagine that the HTTP error
code could be 404 (Not Found) in this case to be more informative, instead
of the current 400.

Richard

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 15:47:29 -0600

On 11/06/2012 01:22 PM, Junchang(Jason) Wang wrote:
> 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

Jason: Right, I discovered that later as well.

> (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, 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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Junchang(Jason) Wang" <[email-masked]>
Date: Tue, 6 Nov 2012 20:53:34 -0500

Learned a lot from this conversation. Thanks all.

(see below)

>  "text/plain" that describes the error in more detail.

We can try to implement this in our ALTO server. But whether it's better to
mention that in some documents so that clients can follow? In other words,
clients should be aware of error description part. Is that right?

Thanks.

--Jason

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 21:00:37 -0600

On 11/06/2012 07:53 PM, Junchang(Jason) Wang wrote:
> On Tue, Nov 6, 2012 at 4:47 PM, Vijay K. Gurbani <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> We can try to implement this in our ALTO server. But whether it's better
> to mention that in some documents so that clients can follow? In other
> words, clients should be aware of error description part. Is that right?

Yes, at least aware enough that they decode the multipart MIME and
render the "text/plain" for human consumption.  But even if they do
not, the problem is apparent when one uses a packet sniffer (tcpdump,
wireshark, etc.) to look at the traffic.

 From the ease of use perspective, using the Reason-Phrase is probably
the way to go.

We could probably have an "Implementer's Guide" section in draft-
gurbani-alto-interop-cases where we provide relevant information.
Probably best to put it there instead of the protocol document.

Thanks,

- vijay

---

From: "Junchang(Jason) Wang" <[email-masked]>
Date: Wed, 7 Nov 2012 11:13:27 -0500

Hi Vijay,

Sounds great. I can implement the Reason-Phrase schema in our ALTO server
soon and deploy it on p4p-1.cs.yale.edu for test.

Thanks.

--Jason

---

From: Richard Alimi <[email-masked]>
Date: Wed, 7 Nov 2012 11:39:03 -0800

On Tue, Nov 6, 2012 at 1:47 PM, Vijay K. Gurbani <[email-masked]> wrote:

> 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
>  JSON-ERR-1 from draft-gurbani-alto-interop-**cases-02.  In that test
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<[email-masked]>
> Web:   http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>
>
> ______________________________**_________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/alto<https://www.ietf.org/mailman/listinfo/alto>
>