Subject: Re: [alto] Large cost-map requests

From: Richard Alimi <[email-masked]>
Date: Thu, 1 Sep 2011 08:13:33 -0700

On Wed, Aug 31, 2011 at 6:26 AM, Bill Roome <[email-masked]> wrote:
> If a server has 1,000 pids, the JSON-encoded full cost map could take >30
> megabytes. 10,000 pids -- ouch!

Note that compression helps quite a bit (and full maps can indeed be
pre-compressed and don't need to be done on-the-fly), but your point
still stands and we should figure out how this is handled.

>  As a result, a server with a large number of pids may be reluctant to
> return the full cost map -- or maybe even the full network map.
> I see several possible solutions:
>
> 1. Require compliant servers to give the full cost map, no matter what it
> takes. If that stresses the server, tough! Don't define that many pids.
>
> 2. Make the full cost map service optional.
>
> 3. Add an E_REQUEST_TOO_LARGE (or whatever) error code to section 7.4.3,
> and allow a server to return that if a request is excessive.
>
> 4. In the ALTO spec, document that a server may return the existing HTTP
> error code "408 -- Request Timeout" if the cost map is too large.
>
> #4 is the easiest, and in any case, we can't stop a server from returning
> that status code. But if the server does, the client can't tell if it's a
> permanent rejection or just a transient glitch. #2 & #3 make it clear that
> the server simply won't return the full cost map, period.

So, there are two cases here it seems.
(1) The person running/configuring the ALTO Server is also control of
the data being served.  In this case, it seems like a configuration
error, and perhaps a HTTP 500 status code would be appropriate.
(2) The person running/configuring the ALTO Server is not in control
of the data being served. Then perhaps a HTTP 502 status code would be
more appropriate?

In either case, my gut feeling says that this is an HTTP issue, and
not an ALTO issue.  Thus, it seems like we should see if an HTTP
status code fits the bill, and if needed, add text to document that.

I'm interested to hear what others have to say about this one.

Thanks,
Rich

>
>        - Bill Roome
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>