Forums » Bugs & Problems Search

Catalog update POST request New Reply

Author Post
Posts: 2
Registered: Jul 05, 2011

Hi,

I'm having sending the correct HTTP request to update an artist catalog. The request sent by my code is:

POST /api/v4/catalog/update?api_key=ECHONESTKEY&format=json HTTP/1.1                                                                                                                                                                 
Accept: application/json
User-Agent: Ruby gem
Content-Type: multipart/form-data;boundary=-----------RubyMultipartPost
Content-Length: 396
Connection: close
Host: developer.echonest.com

-------------RubyMultipartPost
Content-Disposition: form-data; name="id"

ARTISTCATALOG
-------------RubyMultipartPost
Content-Disposition: form-data; name="data"; filename="update.json"
Content-Length: 63
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

[{"item":{"item_id":"OFM76400","artist_name":"Scoop Deville"}}]
-------------RubyMultipartPost--

I get a 400 Bad Request response:

{"response": {"status": {"version": "4.2", "code": 4, "message": "data - Missing Parameter: data is required with a POST content-type of \"application/x-www-form-urlencoded\" or \"multipart/form-data\""}}}

When sending the same file with curl

curl -X POST "http://developer.echonest.com/api/v4/catalog/update?api_key=ECHONESTKEY&format=json" -F "id=ARTISTCATALOG" -F "data=@update.json"

the request is:

POST /api/v4/catalog/update?api_key=ECHONESTKEY&format=json HTTP/1.1                                                                                                                                                                 
User-Agent: curl/7.21.7 (x86_64-unknown-linux-gnu) libcurl/7.21.7 OpenSSL/1.0.0d zlib/1.2.5 libssh2/1.2.7
Host: developer.echonest.com
Accept: */*
Content-Transfer-Encoding: binary
Content-Length: 375
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----------------------------e272283f1033

------------------------------e272283f1033
Content-Disposition: form-data; name="id"

CALGAUX13142CCB16E
------------------------------e272283f1033
Content-Disposition: form-data; name="data"; filename="update.json"
Content-Type: application/octet-stream

[{"item":{"item_id":"OFM76400","artist_name":"Scoop Deville"}}]
------------------------------e272283f1033--

That updates the catalog successfully.

The only difference I see is the Content-Transfer-Encoding and Content-Length headers missing from the curl version of the data part.

Can you spot what's wrong with the first request?

Posts: 40
Registered: Sep 08, 2009

Hello crackofdusk,

I don't see anything immediately wrong with what you're sending. If you remove those headers from your curl request by providing them as empty, does it still work?

you can try this by appending: -H "Content-Transfer-Encoding:" -H "Content-Length:" to your curl request.

Tyler

Posts: 2
Registered: Jul 05, 2011

Maybe I worded it wrong, but they aren't in my curl request. They're in the other one, the one generated by the http library I'm using. I'll look into removing the headers there. Insight on why the request is invalid as is is still welcome, though.

Posts: 2
Registered: Nov 04, 2011

Hi,

I'm having the same issues with multipart posts (using multipart-post ruby gem). After some research, I've found an interesting thing:

When you make a multipart post using curl, only one CRLF sequence is added at the end of the request body, but using multipart-post gem, two CRLF sequences are added. Taking a look at the RFC2046 section 5.1.1, which defines multipart entities syntax, we can see:

There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one.

Maybe the multipart parser expects another form field when it's really the end of the body request. Can you check that?

Thanks.

Posts: 1076
Registered: Sep 08, 2008

edulan - thanks for the sleuthing. We are checking. -- Paul

Reply to this Thread

You must log in to post a reply.