Can extra HTTP headers influence on MWS Feed API submission? - delphi

It is nasty to debug Amazon MWS Feed submissions because whatever you might be doing wrong Ama just returns the same senseless error message:
<Error>
<Type>Sender</Type>
<Code>InvalidParameterValue</Code>
<Message>Either Action or Operation query parameter must be present.</Message>
</Error>
I am 100% positive that I build StringToSign correctly as well as calculate HMAC-SHA256, etc. It took me a few weeks to collect and adopt a stack of useful functions for hashing, signing, base64ing, etc. MWS requests. Written in pure Pascal they were all tested on Orders and Products APIs.
Now when it comes to Feeds API I am stuck on the above error. All parameters are equal to those generated by MWS Scratchpad. I tested the submission StringToSign generated by MWS Scratchpad, but no luck.
What I noticed so far: there is a difference between the number/values of headers generated by MWS Scratchpad and my app.
The Scratchpad generates the following headers (it least they are displayed):
Host: mws.amazonservices.ca
x-amazon-user-agent: AmazonJavascriptScratchpad/1.0 (Language=Javascript)
Content-Type: text/xml
My app uses Indy (in XE4) TIdHTTP to make a request. When Amazon returns the above error, Request.RawHeaders.Text contains the following:
Content-Length: 251
x-amazon-user-agent: MyApp/1.1(Language=Delphi;Platform=Windows7)
Content-Type: text/xml
Host: mws.amazonservices.ca
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: MyApp/1.1(Language=Delphi;Platform=Windows7)
Looks like the extra the headers are added to Request object by default. My first question is: can those extra headers theoretically influence on the behavior? I.e. can they be the showstoppers?
My second question: is there any option to mofidy the list of default heades in Indy HTTP.Request? To go on with the debugging I would rather exclude extra headers to see if the request works.
UPDATE: (SignedString)
AWSAccessKeyId=<AWSAccessKeyId>
&Action=GetFeedSubmissionList
&Merchant=<MerchantId>
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=2015-07-26T09%3A04%3A59Z
&Version=2009-01-01
&Signature=1OI0PVgL3uh5sFXxjCzaaWEwGmW6h5e0dgLUFkPgoXg%3D
UPDATE: (Complete HTTP Request/Response provided by TIdLogFile)
Stat Connected.
Sent 28.07.2015 12:28:11:
POST / HTTP/1.1<EOL>
Content-Type: text/xml; charset=us-ascii<EOL>
Content-Length: 279<EOL>
x-amazon-user-agent: MyAppNameAndVer<EOL>
Host: mws.amazonservices.ca<EOL>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<EOL>
Accept-Encoding: identity<EOL>
User-Agent: Mozilla/3.0 (compatible; Indy Library)<EOL><EOL>
Sent 28.07.2015 12:28:11:
AWSAccessKeyId=<AWSAccessKeyId>
&Action=GetFeedSubmissionList
&MWSAuthToken=<AWSAuthToken>
&Merchant=<MerchantId>
&SignatureMethod=HmacSHA256
&SignatureVersion=2
&Timestamp=2015-07-28T10%3A28%3A09Z
&Version=2009-01-01
&Signature=I6euLIiVDzjZ8bbdtF840K0TJCkGh4NrUbQPtQtu78A%3D
Recv 28.07.2015 12:28:11:
HTTP/1.1 400 Bad Request<EOL>
Date: Tue, 28 Jul 2015 10:28:10 GMT<EOL>
Server: AmazonMWS<EOL>
x-mws-request-id: 7e63280d-1db5-4d10-af40-587747d032a8<EOL>
x-mws-timestamp: 2015-07-28T10:28:11.048Z<EOL>
x-mws-response-context: OmAlguEmW20QT07uIdb9d25xkX+JSS7uFr1rDvXIoqXMvbUFzUMt1b5Xl2WzDaJszbwr25N/J4c=<EOL>
Content-Type: text/xml<EOL>
Content-Length: 324<EOL>
Vary: User-Agent<EOL>
nnCoection: close<EOL><EOL>
<?xml version="1.0"?><LF><ErrorResponse xmlns="https://mws.amazonservices.com/"><LF> <Error><LF> <Type>Sender</Type><LF> <Code>InvalidParameterValue</Code><LF> <Message>Either Action or Operation query parameter must be present.</Message><LF> </Error><LF> <RequestID>7e63280d-1db5-4d10-af40-587747d032a8</RequestID><LF></ErrorResponse><LF>
Stat Disconnected.
Please note: I formatted the response for your convenience adding CRs after <EOL>
Confusing nnCoection header is explained here: Cneonction and nnCoection HTTP headers
My question is now resolved. Below is my way to thank people not breaking the Community standards ;-)
Days := 1;
repeat
IsSuccessful := DebugAmazonFeedSubmissionProc;
Inc(Days);
until IsSuccessful or (Days = 14);
if not IsSuccessful then
begin
AskTheGods(#StackOverflow);
Sleep(1000); // ...wake up and drink a cup'o'tea :)
Expert := TRemyLebeau.Create('delphi');
try
Expert.ReviewTheCode;
Expert.GetTheJobDone;
finally
// You may dispose the instance here,
// but the Class is one of the most valuable assets of the Community.
// Thank you, Remy!
end;
end;

Your request Content-Type header is wrong. You have it set to text/xml; charset=us-ascii, but you are not actually sending XML data to begin with. You need to set the Content-Type (via the TIdHTTP.Request.ContentType property) to application/x-www-form-urlencoded instead, per the MWS GetFeedSubmissionList documentation.
The TStrings version of TIdHTTP.Post() would set the ContentType for you, but you are using the TStream version instead so you have to set the ContentType manually. In this case, I do suggest you switch to the TStrings version, and let it handle encoding the form fields for you:
var
PostData: TStringList;
begin
PostData := TStringList.Create;
try
PostData.Add('AWSAccessKeyId=<AWSAccessKeyId>');
PostData.Add('Action=GetFeedSubmissionList');
PostData.Add('MWSAuthToken=<AWSAuthToken>');
PostData.Add('Merchant=<MerchantId>');
PostData.Add('SignatureMethod=HmacSHA256');
PostData.Add('SignatureVersion=2');
PostData.Add('Timestamp=2015-07-28T10:28:09Z'); // <-- NOT percent encoded yet!
PostData.Add('Version=2009-01-01');
PostData.Add('Signature=I6euLIiVDzjZ8bbdtF840K0TJCkGh4NrUbQPtQtu78A='); // <-- NOT percent encoded yet!
IdHTTP1.Request.CustomHeaders.Values['x-amazon-user-agent'] := 'MyAppNameAndVer';
IdHTTP1.Post('http://mws.amazonservices.ca', PostData);
finally
PostData.Free;
end;
end;

Related

Delphi 10 TRestClient MIME boundary issue

I am trying to consume a REST service using TRestClient but I believe there is an issue with the boundary string for multipart content.
I am capturing the body of the request I am sending, and this is the content type header:
Content-Type: multipart/form-data; boundary=-------Embt-Boundary--07CC944C29DA577E
Then, this is the first section of the multipart form:
-----------Embt-Boundary--07CC944C29DA577E
Content-Disposition: form-data; name="file"; filename="ce.csv"
Content-Type: text/csv
And this is how it ends:
---------Embt-Boundary--07CC944C29DA577E--
I don't think this is an issue on the server, as even my proxy is not able to parse the body:
When I compare this same request vs postman, I notice that the starting and ending boundaries do not match!
Starting: -----------Embt-Boundary--07CC944C29DA577E
Ending: ---------Embt-Boundary--07CC944C29DA577E--
I found that the boundary generation is done in TMultipartFormData.GenerateBoundary() from System.Net.Mime:
When checking the starting and ending boundaries from postman, they match, so I am almost sure this is the issue. I don't think it is related to my code, but let me know if you need it.

What's wrong with this OData batch update query?

I followed the example from here but I cannot get this to work!
I can't see anything wrong with the update query and I can't think of what to change because it seems fine. I'm only testing with one request because I wanted to make sure it works first.
Here's the request's body:
--batch_hJUuHcmH7ADWhYbtkF0o9JWlq
Content-Type: multipart/mixed; boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Content-Type: application/http
Content-Transfer-Encoding: binary
MERGE PrescriptionService.svc/Prescriptions(1L) HTTP/1.1
Host: 192.168.10.179
Content-Type: application/json;odata=verbose
{"PrescriptionType":"RegularMedicationPrescriptionType","Page":"0","Comment":"whoaaaaaa"}
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)--
--batch(hJUuHcmH7ADWhYbtkF0o9JWlq)--
I get a 202 Accepted so the "overall" batch request is not malformed. This is the response from the server:
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c
Content-Type: multipart/mixed; boundary=changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d
--changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d--
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c--
I tried POSTing to that same URL in the batch body to create an entity and it doesn't work either, so it has to be something with the request body.
What's wrong with the request's body?
The changeset boundary as specified in the header:
boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
must match exactly the one used later on:
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Which it doesn't. I don't know why you added the parenthesis, but they should not be there.
Same goes for the batch boundary itself.

I am Unable to Post Xml to Linkedin Share API

I am using Delphi 2010, with Indy 10.5.8(svn version) and oAuth.pas from chuckbeasley. I am able to collect token with app key and App secret, authorize token with a web page and Access the final token. Now I have to post a status with Linkedin’s Share API. I am getting a unauthorized response.
My request and responses are giving bellow.
Request,
POST /v1/people/~/shares HTTP/1.0
Content-Encoding: utf-8
Content-Type: text/xml; charset=us-ascii
Content-Length: 999
Authorization: OAuth oauth_consumer_key="xxx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1340438599",oauth_nonce="BB4C78E0A6EB452BEE0FAA2C3F921FC4",oauth_version="1.0",oauth_token="xxx",oauth_signature="Pz8%2FPz8%2FPz9ePzkxPyc%2FDD82Pz8%3D"
Host: api.linkedin.com
Accept: text/html, */*
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
%3C%3Fxml+version=%25221.0%2522%2520encoding%253D%2522UTF-8%2522%253F%253E%253Cshare%253E%253Ccomment%253E83%2525%2520of%2520employers%2520will%2520use%2520social%2520media%2520to%2520hire%253A%252078%2525%2520LinkedIn%252C%252055%2525%2520Facebook%252C%252045%2525%2520Twitter%2520%255BSF%2520Biz%2520Times%255D%2520http%253A%252F%252Fbit.ly%252FcCpeOD%253C%252Fcomment%253E%253Ccontent%253E%253Ctitle%253ESurvey%253A%2520Social%2520networks%2520top%2520hiring%2520tool%2520-%2520San%2520Francisco%2520Business%2520Times%253C%252Ftitle%253E%253Csubmitted-url%253Ehttp%253A%252F%252Fsanfrancisco.bizjournals.com%252Fsanfrancisco%252Fstories%252F2010%252F06%252F28%252Fdaily34.html%253C%252Fsubmitted-url%253E%253Csubmitted-image-url%253Ehttp%253A%252F%252Fimages.bizjournals.com%252Ftravel%252Fcityscapes%252Fthumbs%252Fsm_sanfrancisco.jpg%253C%252Fsubmitted-image-url%253E%253C%252Fcontent%253E%253Cvisibility%253E%253Ccode%253Eanyone%253C%252Fcode%253E%253C%252Fvisibility%253E%253C%252Fshare%253E
Response,
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
x-li-request-id: K14SWRPEPL
Date: Sat, 23 Jun 2012 08:07:17 GMT
Vary: *
x-li-format: xml
Content-Type: text/xml;charset=UTF-8
Content-Length: 341
Connection: keep-alive
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<error>
<status>401</status>
<timestamp>1340438838344</timestamp>
<request-id>K14SWRPEPL</request-id>
<error-code>0</error-code>
<message>[unauthorized]. OAU:xxx|nnnnn|*01|*01:1340438599:Pz8/Pz8/Pz9ePzkxPyc/DD82Pz8=</message>
</error>
Please help.
Regards,
Vijesh Nair
I cannot comment on the content of your Authentication header, but the rest of your HTTP request is definately not correct, which tells me that you are not using the TIdHTTP.Post() method correctly. In particular, the XML has been url-encoded TWICE (only one of which would have been Indy's doing), and the Content-Encoding header is wrong.
I suspect that you are making the common newbie mistake of posting the XML using the TStrings overloaded version of TIdHTTP.Post(), and also pre-encoding the XML beforehand. Neither of those will work. You must use the TStream overloaded version instead, and do not pre-encode the XML at all.
The correct request should look more like this:
POST /v1/people/~/shares HTTP/1.0
Content-Type: text/xml; charset=utf-8
Content-Length: 571
Authorization: OAuth oauth_consumer_key="xxx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1340438599",oauth_nonce="BB4C78E0A6EB452BEE0FAA2C3F921FC4",oauth_version="1.0",oauth_token="xxx",oauth_signature="Pz8%2FPz8%2FPz9ePzkxPyc%2FDD82Pz8%3D"
Host: api.linkedin.com
Accept: text/html, */*
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
<?xml version="1.0" encoding="UTF-8"?><share><comment>83% of employers will use social media to hire: 78% LinkedIn, 55% Facebook, 45% Twitter [SF Biz Times] http://bit.ly/cCpeOD</comment><content><title>Survey: Social networks top hiring tool - San Francisco Business Times</title><submitted-url>http://sanfrancisco.bizjournals.com/sanfrancisco/stories/2010/06/28/daily34.html</submitted-url><submitted-image-url>http://images.bizjournals.com/travel/cityscapes/thumbs/sm_sanfrancisco.jpg</submitted-image-url></content><visibility><code>anyone</code></visibility></share>
The code to produce that request should look something like this:
var
PostData: TMemoryStream;
begin
PostData := TMemoryStream.Create;
try
WriteStringToStream(PostData, '<?xml version="1.0" encoding="UTF-8"?><share><comment>83% of employers will use social media to hire: 78% LinkedIn, 55% Facebook, 45% Twitter [SF Biz Times] http://bit.ly/cCpeOD</comment><content><title>Survey: Social networks top hiring tool - San Francisco Business Times</title><submitted-url>http://sanfrancisco.bizjournals.com/sanfrancisco/stories/2010/06/28/daily34.html</submitted-url><submitted-image-url>http://images.bizjournals.com/travel/cityscapes/thumbs/sm_sanfrancisco.jpg</submitted-image-url></content><visibility><code>anyone</code></visibility></share>', IndyUTF8Encoding);
PostData.Position := 0;
IdHTTP1.Request.ContentType := 'text/xml';
IdHTTP1.Request.Charset := 'utf-8';
IdHTTP1.Request.CustomHeaders.Values['Authorization'] := 'OAuth oauth_consumer_key="xxx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1340438599",oauth_nonce="BB4C78E0A6EB452BEE0FAA2C3F921FC4",oauth_version="1.0",oauth_token="xxx",oauth_signature="Pz8%2FPz8%2FPz9ePzkxPyc%2FDD82Pz8%3D"';
IdHTTP1.Post('http://api.linkedin.com/v1/people/~/shares', PostData);
finally
PostData.Free;
end;

OData batch multipart format and Content-ID

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.
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

programatically get the file size from a remote file using delphi, before download it

How i can determine the size in bytes of a remote file hosted in the web, before download it, using Delphi?
Thanks In advance.
You could use Indy.
First include IdHTTP.
You can retrieve the size this way:
procedure TFormMain.Button1Click(Sender: TObject);
var
Http: TIdHTTP;
begin
Http := TIdHTTP.Create(nil);
try
Http.Head('http://live.sysinternals.com/ADExplorer.exe');
ShowMessage(IntToStr(Http.Response.ContentLength));
finally
Http.Free;
end;
end;
Short answer: use the HTTP HEAD command, available in the TIdHttp component of Indy Delphi.
Details:
HTTP protocol defines a HEAD method.
9.4 HEAD
The HEAD method is identical to GET
except that the server MUST NOT return
a message-body in the response. The
metainformation contained in the HTTP
headers in response to a HEAD request
SHOULD be identical to the information
sent in response to a GET request.
This method can be used for obtaining
metainformation about the entity
implied by the request without
transferring the entity-body itself.
This method is often used for testing
hypertext links for validity,
accessibility, and recent
modification.
The response to a HEAD request MAY be
cacheable in the sense that the
information contained in the response
MAY be used to update a previously
cached entity from that resource. If
the new field values indicate that the
cached entity differs from the current
entity (as would be indicated by a
change in Content-Length, Content-MD5,
ETag or Last-Modified), then the cache
MUST treat the cache entry as stale.
HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body, retrieving the complete response headers, without the entire content.
The HTTP response headers retrieved are documented in List of HTTP headers on Wikipedia.
http://en.wikipedia.org/wiki/List_of_HTTP_headers
HTTP Headers form the core of an HTTP request,
and are very important in an HTTP response.
They define various characteristics of the data
that is requested or the data that has been provided.
The headers are separated from the request or
response body by a blank line. HTTP headers
can be near-arbitrary strings, but only some
are commonly understood.
One of the headers that is always present for a valid URL to retrieve a content is
the Content-Length header.
14.13 Content-Length
The Content-Length entity-header field indicates the
size of the entity-body, in decimal number of OCTETs,
sent to the recipient or, in the case of the HEAD method,
the size of the entity-body that would have been sent
had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 3495
Applications SHOULD use this field to indicate the
transfer-length of the message-body, unless this is
prohibited by the rules in section 4.4.
Any Content-Length greater than or equal to zero is a
valid value. Section 4.4 describes how to determine
the length of a message-body if a Content-Length is not given.
Note that the meaning of this field is significantly
different from the corresponding definition in MIME,
where it is an optional field used within the
"message/external-body" content-type. In HTTP,
it SHOULD be sent whenever the message's length
can be determined prior to being transferred,
unless this is prohibited by the rules in section 4.4.
From Delphi, drop a TIdHttp component to your form. And paste the following code in one of your delphi event process methods.
var
url: string; // must contain a fully qualified url
contentLength: integer;
begin
....
contentLength:=0;
try
Idhttp1.Head(url);
contentLength:=idhttp1.response.ContentLength;
except end;
....
Be aware that not ALL servers will return a valid content size for a head request. If the content length = 0, then you will ONLY know if you issue a GET request. For example the HEAD request against the Google logo returns a 0 content-length, however a GET returns the proper length, but also retrieves the image. Some servers will return content-length as the length of the packet following the header.
You can use Synapse to get at this information also. Note that the data is transfered, but the buffer is thrown away. This is a much more reliable method, but at the cost of additional bandwidth.
var
HTTP : tHTTPSend;
begin
HTTP := THTTPSend.Create;
try
HTTP.HTTPMethod('GET',url);
DownloadSize := HTTP.DownloadSize;
finally
HTTP.Free;
end;
end;

Resources