0
votes

I'm trying to implement an odata consumer, specifically right now related to doing batch operations and change sets, following the odata documentation essentially loads to this sample multipart batch that I've used as a basis.

However when I actually run this batch code (via fiddler request builder for example) updated with my own entity paths and such, I receive the following error:

Error processing batch request. At the start of every operation, exactly two headers need to be specified: 'Content-Type' and 'Content-Transfer-Encoding'. Make sure these headers are present and have the correct values.

If I remove the Content-ID from the change set the change set works correctly, but obviously the later operations no longer work because they reference this Content-ID.

I've attempted to move the Content-ID header out of the change request multipart.. part headers, and into the actual part payload request headers, ie:

--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621) 
Content-Type: application/http 
Content-Transfer-Encoding: binary 
Content-ID: 1 

POST /service.svc/Customers HTTP/1.1 
Host: host  
Content-Type: application/atom+xml;type=entry 
Content-Length: ### 

<AtomPub representation of a new Customer> 

becomes

--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621) 
Content-Type: application/http 
Content-Transfer-Encoding: binary 

POST /service.svc/Customers HTTP/1.1 
Host: host  
Content-Type: application/atom+xml;type=entry 
Content-Length: ### 
Content-ID: 1 

Again this no longer complains about the change set having only headers, but still the later reference the content id fails with

HTTP 404, Resource not found for the segment '$1'

The request part which references this content-id looks something like this:

--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary

POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json

.. json ..

Assume that http://example.org/test.svc is the service root.

The documentation isn't very clear really about the format of the inner request locations, so the path reference may be incorrect.

Hopefully somebody has better understood this aspect and can advise, thanks in advance.

Stephen.

1

1 Answers

0
votes

Turns out you cannot refer to a change set request if the operation in this way if the operation isn't a POST, this makes sense from the aspect that only POST methods really require this reference, but it would be useful to not need this branching logic.

Importantly however the path when referencing the Content-ID should not be absolute, but instead simply:

POST $1/$links/Resources HTTP/1.1
Content-Type: application/json