Subject: Re: [alto] ALTO error responses & HTTP's Accept header

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 00:30:36 -0700

Hi Ben,

We are revisiting this again as we're making the final push on the
document.  Reading RFC2616, I see the text that you've quoted for the
Accept-Encoding header, but not for the Accept header.  In particular,
http://tools.ietf.org/html/rfc2616#section-14.1 simply states:

   If no Accept header field is present, then it is assumed that the
   client accepts all media types. If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

Given this and the fact that draft-ietf-httpbis-p2-semantics is not yet
published, we are left in the intermediate state.  According to what's
published now, it looks like an ALTO Client should add application/alto-
error+json in its set of accepted content types.  Is that an accurate
understanding?

The followup question to that: if the ALTO Client should add
application/alto-error+json in its list of accepted content types, do we
need to document this in the ALTO Protocol draft?  When discussing this
amongst the editors, our general belief was that if the HTTP spec is not
clear on what should be done, then it's a problem with the HTTP spec and it
should be addressed there and not in the ALTO Protocol spec.  If we do need
to add some text in the ALTO Protocol draft, then perhaps it should be
separated into a discussion section.

A related question is whether the client needs to include
application/alto-directory+json in its list of accepted content types if
the ALTO Server *could* potentially reply with an 300 "Multiple Choices"
formatted as a resource directory.  My reading of RFC2616 and
draft-ietf-httpbis-p2-semantics doesn't turn up any guidance on this, but
my guess is that the ALTO Server could reply with a resource directory even
if the client hasn't included it in the Accept header.

The followup question to this: Do we need to document anything in the ALTO
Protocol draft about this?  The editors' opinion here is similar as above
-- this sounds like something that should be documented in an HTTP spec and
not the ALTO Protocol draft.

Thanks,
Rich

On Wed, Nov 7, 2012 at 12:06 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> Colleagues,
>
> During the ALTO WG session today, a question was raised against the ALTO
> protocol spec about what should the behaviour be when an error occurs but
> the client included an Accept: header in its request but
> application/alto-error+json was not included in the Accept header.
>
> RFC2616 states:
>    If an Accept-Encoding field is present in a request, and if the
>    server cannot send a response which is acceptable according to the
>    Accept-Encoding header, then the server SHOULD send an error response
>    with the 406 (Not Acceptable) status code.
>
> However, draft-ietf-httpbis-p2-semantics (which is currently in WG LC and
> will obsolete RFC2616 when published) states:
>    If an Accept header field is
>    present in a request and none of the available representations for
>    the response have a media type that is listed as acceptable, the
>    origin server MAY either honor the Accept header field by sending a
>    406 (Not Acceptable) response or disregard the Accept header field by
>    treating the response as if it is not subject to content negotiation.
>
> Which confirms what I said at the mic that in the case being considered
> the ALTO server is allowed to return a response with a Content-Type of
> application/alto-error+json if an ALTO error occurs and the client has
> included an Accept header in its request but not included
> application/alto-error+json in the Accept header.
>
> Ben
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 21 Mar 2013 08:46:30 +0000

Hi Rich,

On 21 Mar 2013, at 07:30, Richard Alimi wrote:

> Hi Ben,
> 
> We are revisiting this again as we're making the final push on the document.  Reading RFC2616, I see the text that you've quoted for the Accept-Encoding header, but not for the Accept header.  In particular, http://tools.ietf.org/html/rfc2616#section-14.1 simply states:
> 

But section 10.4.7 says
      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

> Given this and the fact that draft-ietf-httpbis-p2-semantics is not yet published, we are left in the intermediate state.  According to what's published now, it looks like an ALTO Client should add application/alto-error+json in its set of accepted content types.  Is that an accurate understanding?

There aren't any hard rules here AFAIK. I guess strictly speaking if the client has included an Accept header and it supports application/alto-error+json, it should add it to the Accept header.

But the HTTP specs do allow responses other than 406 and I think I'd argue in this case it is more preferable to return the (presumably more descriptive) ALTO error in the hope the client can process it than be picky about returning a 406 without any ALTO error response.

> The followup question to that: if the ALTO Client should add application/alto-error+json in its list of accepted content types, do we need to document this in the ALTO Protocol draft?  When discussing this amongst the editors, our general belief was that if the HTTP spec is not clear on what should be done, then it's a problem with the HTTP spec and it should be addressed there and not in the ALTO Protocol spec.

I think the HTTP spec leaves it open a bit on purpose to let servers choose a "least worst" option based on their specific application.

I'd be tempted to leave things as is rather than overspecify client behaviour and possibly give some advice to server implementors that suggested returning the most descriptive response. Servers will have to handle clients making requests with no Accept header.

>  If we do need to add some text in the ALTO Protocol draft, then perhaps it should be separated into a discussion section.
> 
> A related question is whether the client needs to include application/alto-directory+json in its list of accepted content types if the ALTO Server *could* potentially reply with an 300 "Multiple Choices" formatted as a resource directory.  My reading of RFC2616 and draft-ietf-httpbis-p2-semantics doesn't turn up any guidance on this, but my guess is that the ALTO Server could reply with a resource directory even if the client hasn't included it in the Accept header.

Again I wouldn't get too hung up on it. The way I interpret the Accept header is a way for the client to signal "Given a choice I'd prefer foo over bar", sometimes it may mean "I only support foo" but in those cases if a server doesn't have a foo representation of the resource, returning bar does no harm.

So where the contents of the Accept header affect the server behaviour it is useful to document that in the spec. In other cases where the server may return a different content-type entirely under some circumstances I wouldn't try and articulate all the possibilities.

Ben

> 
> The followup question to this: Do we need to document anything in the ALTO Protocol draft about this?  The editors' opinion here is similar as above -- this sounds like something that should be documented in an HTTP spec and not the ALTO Protocol draft.
> 
> Thanks,
> Rich
> 
> 
> On Wed, Nov 7, 2012 at 12:06 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> Colleagues,
> 
> During the ALTO WG session today, a question was raised against the ALTO protocol spec about what should the behaviour be when an error occurs but the client included an Accept: header in its request but application/alto-error+json was not included in the Accept header.
> 
> RFC2616 states:
> However, draft-ietf-httpbis-p2-semantics (which is currently in WG LC and will obsolete RFC2616 when published) states:
> Which confirms what I said at the mic that in the case being considered the ALTO server is allowed to return a response with a Content-Type of application/alto-error+json if an ALTO error occurs and the client has included an Accept header in its request but not included application/alto-error+json in the Accept header.
> 
> Ben
>

---

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 02:28:25 -0700

Thanks for the fast reply!  A couple of things inline.

On Thu, Mar 21, 2013 at 1:46 AM, Ben Niven-Jenkins
<[email-masked]>wrote:

> published now, it looks like an ALTO Client should add
> application/alto-error+json in its set of accepted content types.  Is that
> an accurate understanding?
>
> There aren't any hard rules here AFAIK. I guess strictly speaking if the
> client has included an Accept header and it supports
> application/alto-error+json, it should add it to the Accept header.
>
> But the HTTP specs do allow responses other than 406 and I think I'd argue
> in this case it is more preferable to return the (presumably more
> descriptive) ALTO error in the hope the client can process it than be picky
> about returning a 406 without any ALTO error response.
>

Ah - thanks for pointing out that additional section.  So based on this,
then would you suggest guidance for ALTO Servers in our protocol spec that
they should return an ALTO Error response in preference to a 406?  We were
hoping to avoid these types of cases where we guide on how to use HTTP.

> should be addressed there and not in the ALTO Protocol spec.
>
> I think the HTTP spec leaves it open a bit on purpose to let servers
> choose a "least worst" option based on their specific application.
>
> I'd be tempted to leave things as is rather than overspecify client
> behaviour and possibly give some advice to server implementors that
> suggested returning the most descriptive response. Servers will have to
> handle clients making requests with no Accept header.
>

Well, the "no Accept header" case is easier - rfc2616 indicates that that
means the client accepts everything :)

Leaving the ALTO Protocol spec as-is is fine with me, modulo my question
above about what to do with the server-side.

>
> >  If we do need to add some text in the ALTO Protocol draft, then perhaps
> it should be separated into a discussion section.
> >
> Again I wouldn't get too hung up on it. The way I interpret the Accept
> header is a way for the client to signal "Given a choice I'd prefer foo
> over bar", sometimes it may mean "I only support foo" but in those cases if
> a server doesn't have a foo representation of the resource, returning bar
> does no harm.
>
> So where the contents of the Accept header affect the server behaviour it
> is useful to document that in the spec. In other cases where the server may
> return a different content-type entirely under some circumstances I
> wouldn't try and articulate all the possibilities.
>

Okay.  Do you think its worth giving any guidance at all in the ALTO
protocol spec?  On one hand, we don't want to duplicate contents of
rfc2616, but on the other, rfc2616 seems to require implementers to
independently come up with something they feel is "reasonable" for these
kinds of cases based on their interpretation of the spec.

Thanks,
Rich

>
> Ben
>
> >
> > The followup question to this: Do we need to document anything in the
> ALTO Protocol draft about this?  The editors' opinion here is similar as
> above -- this sounds like something that should be documented in an HTTP
> spec and not the ALTO Protocol draft.
> >
> > Thanks,
> > Rich
> >
> >
> > However, draft-ietf-httpbis-p2-semantics (which is currently in WG LC
> and will obsolete RFC2616 when published) states:

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 31 Mar 2013 16:29:42 +0100

Richard,

> Thanks for the fast reply!  A couple of things inline.

Not so fast this time I'm afraid :-(

> On Thu, Mar 21, 2013 at 1:46 AM, Ben Niven-Jenkins <[email-masked]> wrote:
> Hi Rich,
> 
> RA>Ah - thanks for pointing out that additional section.  So based on this, then would you suggest guidance for ALTO Servers in our protocol spec that they should return an ALTO Error response in preference to a 406?  We were hoping to avoid these types of cases where we guide on how to use HTTP.

I don't think you need to add any guidance to the spec. At the end of the day an error has occurred and it is unlikely the ALTO client can recover automatically from it so it is unlikely the ALTO client is going to use the ALTO server's behaviour to decide what to do next. So I'd just leave it to ALTO server implementations to decide what they want to do in this case.

> RA> Well, the "no Accept header" case is easier - rfc2616 indicates that that means the client accepts everything :)
> 
> RA> Leaving the ALTO Protocol spec as-is is fine with me, modulo my question above about what to do with the server-side.
>  
> 
> RA> Okay.  Do you think its worth giving any guidance at all in the ALTO protocol spec?

I don't think you need guidance in the spec over and above what you already have.

Ben

>  On one hand, we don't want to duplicate contents of rfc2616, but on the other, rfc2616 seems to require implementers to independently come up with something they feel is "reasonable" for these kinds of cases based on their interpretation of the spec.
> 
> Thanks,
> Rich
>  
> 
> Ben
> 
> >