1
votes

Recently i found that i am getting EConvertError after calling IDHTTP.GET. I analyzed the traffic and saw the expire date on the cookie is 2000. Now my question is how to bypass this. I am using the Indy10 that is present in XE3. I know Indy follows strict standard about cookie handling but shouldn't there be a feature to turn this off ?

URL: https://graph.facebook.com/me?access_token=ACCESS_TOKEN

StackTrace:

:75a5c41f KERNELBASE.RaiseException + 0x58
System.SysUtils.ConvertErrorFmt($412994,(...))
System.SysUtils.StrToInt('')
IdGlobal.IndyStrToInt('')
IdGlobalProtocols.RawStrInternetToDateTime('',0)
IdGlobalProtocols.GMTToLocalDateTime('')
IdHTTPHeaderInfo.TIdEntityHeaderInfo.ProcessHeaders
IdHTTPHeaderInfo.TIdResponseHeaderInfo.ProcessHeaders
IdHTTP.TIdHTTPProtocol.RetrieveHeaders(???)

Response Headers:

(Status-Line)   HTTP/1.1 200 OK
Access-Control-Allow-Origin *
Cache-Control   private, no-cache, no-store, must-revalidate
Content-Type    text/javascript; charset=UTF-8
ETag    "676c539ac3cd7161f5492ce95d72d8b620c6fa6c"
Expires Sat, 01 Jan 2000 00:00:00 GMT
Last-Modified   2012-12-20T20:08:20+0000
P3P CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma  no-cache
X-FB-Rev    702819
X-UA-Compatible IE=edge,chrome=1
Set-Cookie  m_ts=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
Set-Cookie  reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
Set-Cookie  reg_fb_gate=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
Set-Cookie  reg_fb_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com
X-FB-Debug  kZmwuLCRhfhJBKfLoQEbTOBJNyKQGUKLEeJ2R2rcxXg=
Date    Fri, 28 Dec 2012 10:02:19 GMT
Connection  keep-alive
Content-Length  1932
1
The offending date/time string is not coming from a cookie, as the TIdCustomHTTP.ProcessCookies(), TIdCookieManager.AddServerCookies(), and TIdCookie.ParseServerCookie() methods are not included in the call stack you showed. It has to be coming from either the Last-Modified or Expires header (or lack of), as those are the only headers that TIdEntityHeaderInfo.ProcessHeaders() directly calls GMTToLocalDateTime() for without checking for blank values first. - Remy Lebeau
You must not be using an up-to-date version of Indy, because RawStrInternetToDateTime(), and thus GMTToLocalDateTime(), does not raise an exception when passed a blank string, so there has to be a non-blank malformed header value being sent by the server. Please show the actual headers. - Remy Lebeau
@RemyLebeau As you requested. Its the 1970's problem. - Nuno Jemaio
As I said earlier, the error has NOTHING to do with the cookies at all. It is actually the Last-Modified header that is at fault. It is not using a supported string format that conforms to the HTTP-date definition in RFC 2616 Section 3.3 and used by RFC 2616 Section 14.29. That is a bug in Facebook's HTTP server. They should have known better than to use that non-standard format for an HTTP date header. That bug needs to be reported to Facebook. so they can fix it. - Remy Lebeau
Facebook is sending an ISO 8601 formatted date, which is not supported by the HTTP specs. However, I have just checked in an update to Indy so TIdHTTP can now parsee ISO 8601 dates. - Remy Lebeau

1 Answers

1
votes

The offending date/time string is not coming from a cookie, as the TIdCustomHTTP.ProcessCookies(), TIdCookieManager.AddServerCookies(), and TIdCookie.ParseServerCookie() methods are not included in the call stack you showed. It is actually the Last-Modified header that is at fault. Facebook is sending an ISO 8601 formatted date, which is not supported by the HTTP specs. That is a bug in Facebook's HTTP server. They should have known better than to use a non-conforming format for an HTTP date header. That bug needs to be reported to Facebook so they can fix it. In the meantime, I have checked in an update to the latest Indy SVN snapshot so TIdHTTP can now parse ISO 8601 dates.