I'm working on a delphi api for Google docs and having a hard time getting the upload to work. I'm following Google's development guide here and from what I understand it looks like the process should go like this:
Make a POST request to this url: https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false with these headers: X-Upload-Content-Type and X-Upload-Content-Length
Get a 200 OK response with the next upload location stored in the Location header
Make a PUT request to the Location header with the header Content-Type set to whatever I had X-Upload-Content-Type set to in step 1 and the header Content-Range set to something like this: bytes 0-524287/2097152 and the first 512kb of data in the body
Get a 308 Resume Incomplete Response that has the next upload location in the Location header
Go back to 3 until all bytes are uploaded, at which point I will receive a 201 Created response that will have the xml data describing the file I uploaded
Everything up to and including step 3 works fine. It is at step 4 that things start to go wrong.
The one thing that confuses me the most is that the response on step 4 doesn't contain a Location header. I figured that meant I should just send the next request to the same url, but that causes me to get a 504 error. I tried the entire process with fiddler just to see if it was the delphi code, a lack of understanding on my part, or something that google is doing.
Here's the requests and responses I sent and received using fiddler:
POST https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Upload-Content-Type: application/octet-stream
X-Upload-Content-Length: 2097152
Content-Length: 0
Host: docs.google.com
HTTP/1.1 200 OK
Server: HTTP Upload Server Built on May 16 2012 12:03:24 (1337195004)
Location: https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg
Date: Tue, 22 May 2012 16:53:27 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/html
PUT https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg HTTP/1.1
Content-Type: application/octet-stream
Content-Length: 524288
Content-Range: bytes 0-524287/2097152
Host: docs.google.com
[first 512kb of data here]
HTTP/1.1 308 Resume Incomplete
Server: HTTP Upload Server Built on May 16 2012 12:03:24 (1337195004)
Range: bytes=0-524287
X-Range-MD5: bd9d4ee7afa24b7da0e685f05b5f1f44
Date: Tue, 22 May 2012 16:54:29 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/html
PUT https://docs.google.com/feeds/upload/create-session/default/private/full/?access_token=my_access_token&v=3&convert=false&upload_id=AEnB2Ur9-9VxMSI6kaFzbybY2qiyzK6kVoKzcZ6Yo02H8Ni4FlQFl_N06DdjZXzp3vSjOPH3CEb_4vDlKZp7VlC0hxpkypzlKg HTTP/1.1
Content-Type: application/octet-stream
Content-Length: 524288
Content-Range: bytes 524288-1048575/2097152
Host: docs.google.com
[next 512kb of data]
HTTP/1.1 504 Fiddler - Send Failure
Content-Type: text/html; charset=UTF-8
Connection: close
Timestamp: 10:54:14.056
The only thing I was able to do was to be able to say for a fact that it is not just the delphi code that is wrong, and since I don't think it's google, I'm going to have to go with I don't understand something that should be happening. What am I missing?
Edit
I was able to get the upload working, I'm not entirely sure what I did differently, but the documentation is a little misleading. At least it is to me. When you send a PUT request, you don't get a new location, you just continue to upload to the same one. Also, when you finish the upload, the 201 response doesn't contain the actual XML data, instead, it has a Location header that points to where you can grab the XML data from. Not a huge deal but a little confusing.
It seems like the 504 error is returned by Fiddler, these two links should help:
https://urda.com/blog/2010/09/28/iis-services-504s-and-fiddler/
https://urda.com/blog/2010/09/30/follow-up-iis-services-504s-and-fiddler/
Related
The send and receive content on the server I work on is with type "application/xml".
On my init section I added the below line to automatically to add to all my header requests
web_add_auto_header("Content-Type","application/xml");
When I run the script, I get response header showing the correct content-type but in the boo day I get message:
351-byte response headers for "http://172.29.67.68/svc/bw/cti/monitor/event/bw_perfuser1000_60a439f7-599d-4fe1-baa6-598391312954" (RelFrameId=1, Internal ID=5)
HTTP/1.1 200 OK\r\n
Date: Mon, 11 Mar 2019 18:20:09 GMT\r\n
Content-Length: 681\r\n
Content-Type: application/xml\r\n
X-Frame-Options: SAMEORIGIN\r\n
Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n
Cache-Control: no-cache, private, must-revalidate, max-stale=0, post-check=0, pre-check=0
no-store\r\n
Pragma: no-cache\r\n
Keep-Alive: timeout=15, max=96\r\n
Connection: Keep-Alive\r\n
message I get:
HTML parsing not performed for Content-Type "application/xml" ("ParseHtmlContentType" Run-Time Setting is "TEXT").
To fix this issue, I need to add the below line before each request
web_add_header("Content-Type","application/xml");
Can anyone please explain why I need to explicitly mention the content-type before each request although I used the web_add_auto_header() function?
In HTTP protocol, you need to specific Request Header Fields in HTTP request. The detail of HTTP Header please refer to wiki.
I'm trying to get a token from Spotify using the Web API:
My raw request:
POST https://accounts.spotify.com/api/token HTTP/1.1
Authorization: Basic [authsecret]
Content-Type: application/x-www-form-urlencoded
Host: accounts.spotify.com
Content-Length: 490
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=[code]&redirect_url=http%3A%2F%2Flocalhost%3A53575%2FSpotifyLogin.aspx
Where [authsecret] is replaced by the required string (this was broken and gave me a different error, but now I fixed it) and [code] is replaced by the code returned a step earlier by Spotify.
I get the following response:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Thu, 22 Jun 2017 13:50:33 GMT
Content-Type: application/json
Content-Length: 68
Connection: keep-alive
Keep-Alive: timeout=600
{"error":"invalid_grant","error_description":"Invalid redirect URI"}
I must be doing something wrong, but I can't figure it out. Can anyone help me?
I've figured it out. Issue is the parameter name redirect_url. It should be redirect_uri. Small mistake but breaks the request as it should.
Recently I found a phenomenon of jetty. In eclipse I installed a jetty plugin to run web project. In page(jsp) there is a ajax request, I found if project is started by jetty there is 500 error, but if started by tomcat, it's ok. See below:
curl -d "category=foo" 'http://localhost:8080/foo/bar' -i
HTTP/1.1 200 OK
Date: Tue, 22 Dec 2015 13:27:35 GMT
Content-Type: text/html;charset=utf-8;charset=UTF-8
Cache-Control: no-cache
Expires: 0
Pragma: no-cache
Content-Length: 20086
Server: Jetty(8.1.14.v20131031)
curl: (18) transfer closed with 20086 bytes remaining to read
please warning content type header above, charset is duplicate, so cause this error.
Then I changed code of setting content type, request again, it's ok now.
HTTP/1.1 200 OK
Date: Thu, 24 Dec 2015 03:00:33 GMT
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache
Expires: 0
Pragma: no-cache
Content-Length: 83
Server: Jetty(8.1.14.v20131031)
{"altMessage":null,"desc":null,"map":null,"message":"[]","prop":null,"rsCode":"ok"}
So I'd like to know why Jetty can't support duplicate charset in Content Type header?
I did a quick test in jetty-9.3 and the following test passes fine:
#Test
public void testStrangeContentType() throws Exception
{
Response response = newResponse();
assertEquals(null, response.getContentType());
response.recycle();
response.setContentType("text/html;charset=utf-8;charset=UTF-8");
response.getWriter();
assertEquals("text/html;charset=utf-8;charset=UTF-8",response.getContentType());
assertEquals("utf-8",response.getCharacterEncoding().toLowerCase());
}
So this looks like it is fixed in the latest jetty releases. Jetty-8 has been end of life for some time so can you upgrade?
Looks like a bug.
It's been filed at the RT/Jetty issue tracker under https://bugs.eclipse.org/485376
I have a quick question but in advance I've read the RFC 2616 Chapter 14.22 about Host and HTTP Header but I still not understand where in httpd.conf or configuration file of a webserver should be changed? Please correct me if I'm wrong.
Look at following two HTTP GET I did to an Apache. The first one is GET for HTTP 1.0 , the other one is GET for HTTP 1.1. See the output:
HTTP/1.0 200 OK
Date: Thu, 24 Oct 2013 03:46:22 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Vary: *
Last-Modified: Fri, 10 Aug 2012 20:22:30 GMT
ETag: "17c815b-3b-50256d86"
Accept-Ranges: bytes
Content-Length: 59
Connection: close
Content-Type: text/html
<html>
<body>
<center>webli7</center>
</body>
</html>
HTTP/1.1 400 Bad Request
Date: Thu, 24 Oct 2013 04:04:40 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
16e
The HTTP protocol version is decided dynamicaly, not through configuration files. The client send a request specifying the highest protocol version that its support. Then, the server must respond with either the version requested by the client, or any earlier version that it prefers.
Since Apache does support HTTP/1.1, it should therefore match exactly the version provided by the client.
There exist a flag that you may set in Apache's config to force Apache to use HTTP/1.0 in certain situations, even though the browser requested HTTP/1.1. This is used to fix bugs in HTTP/1.1 handling of some very old browser. Today, you should not need to play with this flag.
As for your error, I would suggest that you make sure that your GET does provide the Host: header. This header is required in HTTP/1.1, yet optional in HTTP/1.0, and having it missing would certainly result in a 400 error.
I have a script on GAE that requests an XML feed from a partner that's typically 40MB but only 5MB gzipped. GAE is automatically unzipping this content and throwing an error that the response is too big:
HTTP response was too large: 46677241. The limit is: 33554432.
The script is setup to uncompress the response itself. How do I prevent GAE from getting in the way and breaking?
Here's the response header from my partner:
HTTP/1.0 200 OK
Expires: Wed, 27 Jun 2012 05:42:07 GMT
Cache-Control: max-age=10368000
Content-Type: application/x-gzip
Accept-Ranges: bytes
Last-Modified: Wed, 22 Feb 2012 11:06:09 GMT
Content-Length: 5263323
Date: Tue, 28 Feb 2012 05:42:07 GMT
Server: lighttpd
X-Cache: MISS from static01
X-Cache-Lookup: MISS from static01:80
Via: 1.0 static01:80 (squid)
Most likely your partner's server responds with plain XML, because it thinks that http-client sending requests (i.e. GAE URL Fetch service) does not support gzipping. Hence "response was too large" error.
To announce that you actually want to receive gzipped content you need to set Accept-Encoding: gzip header when using URL fetch service.