I am trying to integrate the oauth flow in my application.
I am getting a 401 when calling the oauth/request_token endpoint with this error:
"message": "401 - {\"errors\":[{\"code\":135,\"message\":\"Timestamp out of bounds.\"}]}"
This is my authorization header:
"Authorization": "OAuth oauth_callback=http%3A%2F%2F127.0.0.1%3A3000%2Ftwitter%2Foauth_callback,oauth_consumer_key=MYKEY,oauth_nonce=150255341200200,oauth_signature_method=HMAC-SHA1,oauth_timestamp=1502553412002,oauth_version=1.0,oauth_signature=d09f2f2a39e51909442ae6ca717e4aeba7066fda"
I can see in the response header that the server time for Twitter is:“date”: “Sat, 12 Aug 2017 15:56:52 GMT”
If I take my timestamp and convert it to a GMT date I get:
Saturday, August 12, 2017 3:56:52.002 PM
I am not sure why it is considered out of bounds.
The oauth_timestamp should be the number of whole seconds since 1 Jan 1970 00:00:00 UTC.
Your timestamp is out by a factor of around 1000! It should have been:
oauth_timestamp=1502553412
For timestamp value, please use the below piece of code:
Math.floor((new Date()).getTime() / 1000);
My URL has start parameter as 2015-06-11T11:34+01:00
URL: /admin?start=2015-06-11T11:34+01:00
start_date = params[:start]
When I try to display start_date, I receive 2015-06-11T11:34 01:00 which has + missing. start_date.to_time displays 2015-06-11 11:34:00 UTC. This means it doesn't matter what I send after + i.e., +01:00 or +05:00.
In my ruby console I correctly receive start_date as 2015-06-11 10:24:00 UTC
Please let me know how to retrieve the value of start parameter without the +01:00 getting ignored.
Get the param value as a string:
start_date = params[:start].to_s
Already been through RFC 4469.
Just wanted to know how exactly I can use the CATENATE command.
I also referred the example given in the RFC. But couldn't really execute it against the server.
Any help will be appreciated.
I know this is old issue, but since I was looking this myself, and noticed this I thought I'd share what I found.
So. The simple examples:
s SELECT INBOX
a APPEND INBOX (\Seen) CATENATE (TEXT {53+}
Date: Tue, 03 Jan 2017 22:39:40 +0200
Hello, world.
)
This will work with modern system. You can also use
s SELECT INBOX
a APPEND INBOX (\Seen) CATENATE (TEXT {53}
Date: Tue, 03 Jan 2017 22:39:40 +0200
Hello, world.
)
The thing about catenate is that it can also combine input from other emails. You can do this with URL.
a APPEND INBOX CATENATE (URL "/INBOX;UIDVALIDITY=1483364905/;UID=2/;SECTION=HEADER" TEXT {8}
Hello..
)
a OK [APPENDUID 1483364905 4] Append completed.
FETCH 4:4 (BODY[])
Date: Tue, 03 Jan 2017 22:39:40 +0200
Hello..
)
a OK Fetch completed.
And we have reused headers from mail with UID 2 in INBOX. UIDVALIDITY can be acquired by saying s STATUS INBOX.
The examples in the IETF are bit spooky, but they show how to use mime multipart as input.
<DIV id=3949 class=tempClass channel-name="Brand" sizcache="50" nodeIndex="1" jQuery1362033550328="46"></div>
What is [jQuery1362033550328="46"]? It is showing in IE only not firefox.
1362033550328 is the unix timestamp which is equivalent to Thu, 28 Feb 2013 06:52:00 GMT
Mostly its appended along with ajax requests to avoid ajax cache problems
I'm working on a small single-page application using HTML5. One feature is to show PDF documents embedded in the page, which documents can be selected form a list.
NOw I'm trying to make Chrome (at first, and then all the other modern browsers) use the local client cache to fulfill simple GET request for PDF documents without going through the server (other than the first time of course). I cause the PDF file to be requested by setting the "data" property on an <object> element in HTML.
I have found a working example for XMLHttpRequest (not <object>). If you use Chrome's developer tools (Network tab) you can see that the first request goes to the server, and results in a response with these headers:
Cache-Control:public,Public
Content-Encoding:gzip
Content-Length:130
Content-Type:text/plain; charset=utf-8
Date:Tue, 03 Jul 2012 20:34:15 GMT
Expires:Tue, 03 Jul 2012 20:35:15 GMT
Last-Modified:Tue, 03 Jul 2012 20:34:15 GMT
Server:Microsoft-IIS/7.5
Vary:Accept-Encoding
The second request is served from the local cache without any server roundtrip, which is what I want.
Back in my own application, I then used ASP-NET MVC 4 and set
[OutputCache(Duration=60)]
on my controller. The first request to this controller - with URL http://localhost:63035/?doi=10.1155/2007/98732 results in the following headers:
Cache-Control:public, max-age=60, s-maxage=0
Content-Length:238727
Content-Type:application/pdf
Date:Tue, 03 Jul 2012 20:45:08 GMT
Expires:Tue, 03 Jul 2012 20:46:06 GMT
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*
The second request results in another roundtrip to the server, with a much quicker response (suggesting server-side caching?) but returns 200 OK and these headers:
Cache-Control:public, max-age=53, s-maxage=0
Content-Length:238727
Content-Type:application/pdf
Date:Tue, 03 Jul 2012 20:45:13 GMT
Expires:Tue, 03 Jul 2012 20:46:06 GMT
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*
The third request for the same URL results in yet another roundtrip and a 304 response with these headers:
Cache-Control:public, max-age=33, s-maxage=0
Date:Tue, 03 Jul 2012 20:45:33 GMT
Expires:Tue, 03 Jul 2012 20:46:06 GMT
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT
Server:Microsoft-IIS/8.0
Vary:*
My question is, how should I set the OutputCache attribute in order to get the desired behaviour (i.e. PDF requests fullfilled from the client cache, within X seconds of the initial request)?
Or, am I not doing things right when I cause the PDF to display by setting the "data" property on an <object> element?
Clients are never obligated to cache. Each browser is free to use its own heuristic to decide whether it is worth caching an object. After all, any use of cache "competes" with other uses of the cache.
Caching is not designed to guarantee a quick response; it is designed to, on average, increase the likelihood that frequently used resources that are not changing will already be there. What you are trying to do, is not what caches are designed to help with.
Based on the results you report, the version of Chrome you were using in 2012 decided it was pointless to cache an object that would expire in 60 seconds, and had only been asked for once. So it threw away the first copy, after using it. Then you asked a second time, and it started to give this URL a bit more priority -- it must have remembered recent URLs, and observed that this was a second request -- it kept the copy in cache, but when the third request came, asked server to verify that it was still valid (presumably because the expiration time was only a few seconds away). The server said "304 -- not modified -- use the copy you cached". It did NOT send the pdf again.
IMHO, that was reasonable cache behavior, for an object that will expire soon.
If you want to increase the chance that the PDF will stick around longer, then give a later expiration time, but say that it must check with the server to see if it is still valid.
If using HTTP Cache-Control header, this might be: private, max-age: 3600, must-revalidate. With this, you should see a round-trip to server, which will give 304 response as long as the page is valid. This should be a quick response, since no data is sent back -- the browser's cached version is used.
private is optional -- not related to this caching behavior -- I'm assuming whatever this volatile PDF is, it only makes sense for the given user and/or shouldn't be hanging around for a long time, in some shared location.
If you really need the performance of not talking to the server at all, then consider writing javascript to hide/show the DOM element holding that PDF, rather than dropping it, and needing to ask for it again.
Your javascript code for the page is the only place that "understands" that you really want that PDF to stick around, even if you aren't currently showing it to the user.
Have you tried setting the Location property of the OutputCache to "Client"
[OutputCache(Duration=60, Location = OutputCacheLocation.Client)]
By default the location property is set to "Any" which could mean that the response is cached on the client, on a proxy, or at the server.
more at MSDN OutputCacheLocation