GET with Storlet execution generates wrong content with automatic retry in proxy-server

[Takashi Kajinami]

When proxy-server gets timeout while it is transferring object in GET, it automatically retry to another object-server to get the rest of the object content using range header.

When it happens while executing storlets, we get the object content modified with storlet at first, then get the original object content(because object-server doesn't execute storlets when it finds range header) after that retry.
As the result, we get the very odd content, consists of modified content and original content.

[Eran Rom (eranr)]

During the IRC call we have identified two different semantics for storlets with ranges
1. The range specifies the input range for the storlet. That is the storlet is executed on the specified range of the input object. In the below I refer to this as 'input range' semantics
2. The range specifies the output range. That is the storlet is executed on the object from its beginning and the storlet returns only the required range. In the below I refer to this as 'output range' semantics

We have reached the following understandings w.r.t. the range semantics:
* For 'input range' semantics we should use a proprietary header, e.g. X-Storlet-Range that may be added on top of
  X-Run-Storlet. At this point I suggest to support a single range.
  Moreover, since the storlet output in this case is not known in advance and hence we use chunked transfer encoding, the usage of a
  proprietary header helps us bypass HTTP RFC problem, where it is not clear what the returned code should be.

* For 'output range' semantics we should use HTTP standard range headers (plus X-Run-Storlet). In this case either the storlet does not produce the range ans we return 412 or the storlet outputs the exact range and we can return 206. Again, we may want to start with a single range.

Now, for this particular bug (and the related 1534455 bug) we decided to currently do the following:
1. Not support 'output range' semantics. That is return 400 bad request for X-Run-Storlet which carries a range header.
2. Change the current support for 'input range' semantics to be used with X-Storlet-Range - I suggest a single range at this point - and if the proxy gets a timeout and issues a ranged get to another object server (as discussed in this bug) fail the request altogether by not accepting X-Run-Storlet + range at the object servers.

eranrom is to update the docs accordingly.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/282931

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/282931
Committed: https://git.openstack.org/cgit/openstack/storlets/commit/?id=c5775b2202f89ac582485c3ac0f6d6e365a2a11a
Submitter: Jenkins
Branch: master

commit c5775b2202f89ac582485c3ac0f6d6e365a2a11a
Author: Takashi Kajinami <email address hidden>
Date: Mon Feb 22 10:47:29 2016 +0900

    Prohibit storlet execution with range header

    Storlet execution with range header now violates RFC 7233 in the
    following two points, so this patch prohibits storlet execution
    with range header.

    * It returns 200 OK for range request, but it should return 206
      Partial Content.
    * Content-Range header in response shows the range of the raw
      response, and usually is inconsistent with the storlet response.

    This patch also fixes wrong behavior in storlet_handler, when
    resuming feature in proxy-server works.

    NOTE: The new header to specify input range is going to be added
    by another patch.

    Change-Id: Ie030ed5f8ddbe47b45687e56861be73e2758fb5b
    Closes-bug: #1534414