I have a problem I'm trying to use the component idhttp using indy in delphi 2010, the problem is I'm trying to get the following information when using idHTTP1.Head ():
HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 2:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat / Linux)
Last-Modified: Wed, October 7, 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text / html
The problem is not that I have to do to get this information because I can not get with idHTTP1.Request.RawHeaders.Values, someone could say that I have to do.
You are looking in the wrong place. You need to look in IdHTTP1.**Response**.RawHeaders instead. Also, all of those values actually have individual properties associated with them, eg:
IdHTTP1.Response.ResponseVersion
IdHTTP1.Response.ResponseCode
IdHTTP1.Response.ResponseText
IdHTTP1.Response.Date
IdHTTP1.Response.Server
IdHTTP1.Response.LastModified
IdHTTP1.Response.ETag
IdHTTP1.Response.AcceptRanges
IdHTTP1.Response.ContentLength (also IdHTTP1.Response.HasContentLength)
IdHTTP1.Response.Connection
IdHTTP1.Response.ContentType
Related
I have a program that downloads files and realized that by downloading using the program the speed hangs at 300kbps, however downloading the same file using a browser doubles the speed. I have seen in some posts about using ranges to separate the file into parts and download using threads, but I could not implement it.
My code:
IdHTTP1.Head(URL);
Range: = IdHTTP1.Request.Ranges.Add;
Range.StartPos: = 0;
Range.EndPos: = Trunc(IdHTTP1.Response.ContentLength / 2);
IdHTTP1.Post(URL, Parameters, FS);
When I run the code, it returns me the whole file, i'm not sure if this code is correct, I tried to do something simple to test, but it did not work.
When I use IdHttp.Head() the raw header returns this information:
Date: Mon, 29 May 2017 18:02:11 GMT
Pragma: No-cache
Cache-Control: no-cache, no-store, max-age = 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Disposition: attachment; filename = "pecas.pdf"
Content-Type: application / pdf
Content-Length: 18507774
I checked mochiweb response headers, and they are always ordered (descending):
< Server: MochiWeb/1.0 (Any of you quaids got a smint?)
< last-modified: Sun, 30 Aug 2015 23:13:04 GMT
< Date: Sun, 30 Aug 2015 23:15:15 GMT
< Content-Type: text/html
< Content-Length: 89
This looks to be because of mochiweb headers are being handled with an erlang gb_tree, which is later converted to a list so it comes ordered.
Is there a way to change this? as this could resolve in problems (sometimes) like here and here
My problem is that I am trying to create a service that replicates some requests and I am using mochiweb for this, but Headers are being ordered so it isn't completely replicating the response correctly.
Fixed here:
mochiweb commit 952087e
It was a problem with formatting the headers in the response, and not in mochiweb_headers.
I'm having problems with sending a stream to the client internet browser when he types the host and port my TCPServer listens to. When I type :
AContext.Connection.IOHandler.Write(clientResponseStream);
in my TCPServer OnExecute event the only way to send the information to the client's browser is If I make my server inactive.
TCPServer.Active := False
-> only after this there is some information in his browser. And it is not the whole data - some pictures are there, some are missing. Can someone help me how to send my (whole) data without having to disconnect my server ?
For every GET request (in my OnExecute event) I have HTTP response that my TCPClient receives with
TCPClient.IOHandler.ReadStream(cStream, cStream.Size, False);
that lookes kinda like this :
HTTP/1.1 200 OK
Server: nginx/1.4.7
Date: Thu, 08 May 2014 18:46:43 GMT
Content-Type: application/x-javascript
Last-Modified: Fri, 28 Mar 2014 09:54:42 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
1a89
// some jquery here ...
and I send this data with
AContext.Connection.IOHandler.Write(cStream);
There is a method in AFNetworking that can set image conveniently:
- (void)setImageWithURL:(NSURL *)url
placeholderImage:(UIImage *)placeholderImage
but if the url image have no extension(like http://static.qyer.com/album/user/330/21/QkpVQBsHaA/670), there are some problems,sometimes the image can be displayed exactly some times it is not displayed.
I found a method
[AFImageRequestOperation addAcceptableContentTypes:<#(NSSet *)contentTypes#>];
how should I set the contentTypes?
If you curl the URL provided, you can see the problem:
curl -i -X HEAD http://static.qyer.com/album/user/330/21/QkpVQBsHaA/670
HTTP/1.0 200 OK
Server: nginx/1.0.11
Date: Fri, 29 Mar 2013 02:03:24 GMT
Content-Type: application/octer-stream
Last-Modified: Tue, 19 Mar 2013 09:40:23 GMT
ETag: "53430075-9814c-4d843e4fc6fc0"
Accept-Ranges: bytes
Content-Length: 622924
Powered-By-ChinaCache: MISS from 060531Q354
Powered-By-ChinaCache: MISS from 060532235y
Connection: close
Content-Type: application/octer-stream (which is, strangely, a misspelling of application/octet-stream), is not a valid image mime type. If you have any control over the server, I would strongly recommend you fix this to send real mime types—for the sake of everyone accessing the CDN.
Otherwise, I would recommend you add */* to the list of acceptable content types. This should accept anything thrown at it. You can also manually specify any content types you might expect the CDN to serve, including application/octer-stream.
I am viewing an HTML page in a standard iOS UIWebView. Inside this page I have a standard YouTube embed, something like this:
<iframe id="video-play" width="624" height="350" src="http://www.youtube.com/embed/hBLf_N-T0vI" allowfullscreen class="hide fade"></iframe>
This works fine in all cases on the browser, and in most cases in a UIWebView. But for some videos I get the (I think misleading) message:
"The uploader has not made this video available in your country."
The problem is somewhere in the get_video_info call, and related to the fact that from a UIWebView it seems the eurl paramter is set to "unknown"
So this request works from within a UIWebView:
http://www.youtube.com/get_video_info?html5=1&video_id=hBLf_N-T0vI&eurl=unknown&ps=native&el=embedded&hl=en_GB
This fails, with errorcode 150 and the error message I mentioned above (it will work fine in a browser so use the raw HTTP request below)
http://www.youtube.com/get_video_info?html5=1&video_id=DldaCQby3j4&eurl=unknown&ps=native&el=embedded&hl=en_GB
If I change the eurl=unkown into eurl=http://rubbish.com/ then it works again:
http://www.youtube.com/get_video_info?html5=1&video_id=DldaCQby3j4&eurl=http://rubbish.com&ps=native&el=embedded&hl=en_GB
I've tried to look at the properties of the videos that are failing but can't figure out what is causing the difference between the good ones and the bad ones. I've looked at embed settings, privacy and tracking settings and anything else I can think of.
My other option is to figure out how to add an eurl paramter to the request.
Help!
Jon
If anyone wants the full HTTP requests/response:
BAD REQUEST
GET /get_video_info?html5=1&video_id=DldaCQby3j4&eurl=unknown&ps=native&el=embedded&hl=en_GB HTTP/1.1
Host: www.youtube.com
BAD RESPONSE
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2012 15:42:47 GMT
Server: gwiseguy/2.0
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: *
Set-Cookie: use_hitbox=d5c5516c3379125f43aa0d495d100d6ddAEAAAAw; path=/; domain=.youtube.com
Set-Cookie: VISITOR_INFO1_LIVE=fH943IGDAFc; path=/; domain=.youtube.com; expires=Sun, 21-Jul-2013 15:42:47 GMT
Expires: Tue, 27 Apr 1971 19:44:06 EST
Cache-Control: no-cache
P3P: CP="This is not a P3P policy! See //support.google.com/accounts/bin/answer.py?answer=151657&hl=en-US for more info."
Content-Type: application/x-www-form-urlencoded
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked
status=fail&errorcode=150&reason=The+uploader+has+not+made+this+video+available+in+your+country.&storyboard_spec=http%3A%2F%2Fi1.ytimg.com%2Fsb%2FDldaCQby3j4%2Fstoryboard3_L%24L%2F%24N.jpg%7C48%2327%23100%2310%2310%230%23default%23w3GCNZfS0BvXcAQIB1BBnUJRlrY%7C80%2345%23112%2310%2310%232000%23M%24M%23VDmT14lMI4g0sdAxTbIujmEIkkI%7C160%2390%23112%235%235%232000%23M%24M%23c1uKcYcKallke_fsXgoUOkSHnwA&errordetail=0
GOOD REQUEST
GET /get_video_info?html5=1&video_id=DldaCQby3j4&eurl=http%3A%2F%2Frubbish.com%2F&ps=native&el=embedded&hl=en_GB HTTP/1.1
Host: www.youtube.com
GOOD RESPONSE
HTTP/1.1 200 OK
Date: Fri, 23 Nov 2012 15:42:34 GMT
Server: gwiseguy/2.0
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: *
Set-Cookie: use_hitbox=d5c5516c3379125f43aa0d495d100d6ddAEAAAAw; path=/; domain=.youtube.com
Set-Cookie: VISITOR_INFO1_LIVE=zG2n4ZwVAdY; path=/; domain=.youtube.com; expires=Sun, 21-Jul-2013 15:42:33 GMT
Expires: Tue, 27 Apr 1971 19:44:06 EST
Cache-Control: no-cache
P3P: CP="This is not a P3P policy! See //support.google.com/accounts/bin/answer.py?answer=151657&hl=en-US for more info."
Content-Type: application/x-www-form-urlencoded
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked
account_playback_token .... (chopped for brevity).
Could something to do with "claimed" videos. A contact at YouTube got back to us:
"The videos [that worked] are claimed and the others aren't, so
something in the claiming process is causing the issue."