How can I send a POST to ThingSpeak through www.requestmaker.com?
I'm using this:
POST /update HTTP/1.1
Host: api.thingspeak.com
Connection: close
X-THINGSPEAKAPIKEY: XXXXXXXXXXXXXXXX
Content-Type: application/x-www-form-urlencoded\
Content-Length: 24
field1=34&field2=1
But I get this response:
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8
Content-Length: 728
Connection: close
Status: 404 Not Found
X-Request-Id: 36c8113c-3671-4302-85fa-f3ecdba364dc
X-Runtime: 0.019035
X-Powered-By: Phusion Passenger 4.0.57
Date: Mon, 19 Dec 2016 02:36:42 GMT
Server: nginx/1.9.3 + Phusion Passenger 4.0.57
Any solution?
Make sure you have the right API key -- it's common to get zeros and the letter 'O' incorrect. What API end point are you writing to? You can get help on the ThingSpeak forum: http://community.thingspeak.com/forum/
Related
My application uses Varnish 3.0.2. I am facing a weird problem here. Some of the times the pages are served from Varnish with a HIT. But immediately after it returns MISS.
I was under the impression that once it gets served from the cache, it will continue to do so until the TTL expires. Am I wrong in understanding that?
Here are the two response headers for both the scenario:
HIT
HTTP/1.1 200 OK
Server: Apache/2.4.16 (Unix) mod_auth_kerb/5.4 PHP/5.3.29
X-Powered-By: PHP/5.3.29
X-Drupal-Cache: MISS
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
cache-control: max-age=86400, public
X-Cookie-Debug: Request cookie:
X-Request-URL: /org/31633421?unit=31633421
Content-Length: 11986
Accept-Ranges: bytes
Date: Wed, 24 Apr 2019 14:26:43 GMT
X-Varnish: 330015711 330015651
Via: 1.1 varnish
Connection: keep-alive
X-Varnish-Cache: HIT
X-Varnish-Cache-Hits: 1
X-Varnish-Age: 188
X-Varnish-Leg: 128.87.225.172
X-Varnish-Cache-Version: 3.0.2
MISS
HTTP/1.1 200 OK
Server: Apache/2.4.16 (Unix) mod_auth_kerb/5.4 PHP/5.3.29
X-Powered-By: PHP/5.3.29
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=300
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cookie-Debug: Request cookie: _gat_UA-15166137-36=1
X-Request-URL: /org/31633421?unit=31633421
Content-Length: 11978
Accept-Ranges: bytes
Date: Wed, 24 Apr 2019 14:23:52 GMT
X-Varnish: 1900997574
Via: 1.1 varnish
Connection: keep-alive
X-Varnish-Cache: MISS
X-Varnish-Age: 0
X-Varnish-Leg: 128.87.225.158
X-Varnish-Cache-Version: 3.0.2
I have tried to increase the TTL value, remove all the cookies (including Google Analytics) but still it's behaving abruptly.
Any idea why?
Update
Seems like this is happening for including the following Google Tag manager JS code in my view template.
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXX');</script>
Turns out it WAS actually a problem in the VCL configuration with the regex I was using. I had not considered the non-alpha characters of the Google Ananlytics cookie. Modified the regex to _[_\-\.\=a-zA-Z0-9] and everything is fun again!
Hope this helps somebody.
My guess is that it comes from two different varnish servers based on the two response headers:
X-Varnish-Leg: 128.87.225.172
and
X-Varnish-Leg: 128.87.225.158
+1 for Ronald, also please consider upgrading to the latest Varnish 6 as years have passed since Varnish 3, many bugs have been fixed and improvements built. Furthermore V3 is end of life.
In particular, I have this response header from an nginx server:
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Tue, 20 Mar 2018 10:28:24 GMT
Content-Type: text/html
Last-Modified: Thu, 28 Jan 2016 10:50:21 GMT
Connection: keep-alive
ETag: W/"56a9f26d-2d97"
Content-Encoding: gzip
Followed by some 3352 Bytes of compressed data. I'm trying to find out how does the client know where the body of this message ends and a new response begins.
It doesn't. The response requires either a Content-Length response header field, or it has to use "Transfer-Encoding: chunked".
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.
When I view the URL below or the other below in the code it's displayed fine. I don't see anything unusual in the network tab when I press F12 in the browser, but with the code below I will get response codes 403 or 400. When I use the response code checker here http://httpstatus.io/ it will come back fine with a 200 response for both URLS.
I get a 403 for http://psychsignal.com/ using my code below.
URL u = new URL("http://www.nasdaqomxnordic.com/"); //returns 400 response code
//u.toURI(); //to check the syntax
HttpURLConnection huc = (HttpURLConnection)u.openConnection();
huc.setRequestMethod("GET");
//huc.setRequestMethod("HEAD");
huc.connect();
System.out.println(huc.getResponseCode());
Thanks if anyone has any ideas! This is actually my first post!
My guess is that there's some restrictions placed on the User-Agent of the client. Some testing seems to support my theory:
If I use the curl default user agent:
# curl -I -H "User-Agent: curl/7.35.0" "http://www.nasdaqomxnordic.com/"
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Connection: close
If I use a hacked up standard browser agent string:
# curl -I -H "User-Agent: Mozilla/5.0" -0 "http://www.nasdaqomxnordic.com/"
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Content-Type: text/html;charset=UTF-8
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 22 Jul 2015 15:06:22 GMT
Connection: close
And then if I use a Java agent string (which is my guess as to what you're using):
# curl -I -H "User-Agent: Java/1.6.0_26" "http://www.nasdaqomxnordic.com/"
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Connection: close
Only the "browser" user agent gets through. I'd try tweaking your code to set the user agent string to something commonly found in a web browser.
This is the raw HTTP call that I make to verify authentication. It returns the expected response:
GET /1/account/verify_credentials.xml HTTP/1.1
Authorization: OAuth oauth_token="12556442-pndSo1mf2i1ToPSbAyLH4qBBDHmtyutjbvMLckGER",oauth_consumer_key="ih75ityikrTdIwB9kQ",oauth_nonce="6wIbdfxL",oauth_signature_method="HMAC-SHA1",oauth_signature="7DUW5TLtntryndfhU5dSXARg%3D",oauth_version="1.0",oauth_timestamp="1267805254"
Host: api.twitter.com
This is a call that I (try) to make, which is intended to update the users status:
POST /1/statuses/update.xml HTTP/1.1
Authorization: OAuth oauth_token="1252356242-pndSo1mf2i1ToPSfghfghfQoMLckGER",oauth_consumer_key="ih75i83BXdfhnfghnfgQ",oauth_nonce="CJ9dfgXs",oauth_signature_method="HMAC-SHA1",oauth_signature="bSD7aXUdfghdfghfghfghoU%3D",oauth_version="1.0",oauth_timestamp="1267235407"
Content-Type: application/x-www-form-urlencoded
Host: api.twitter.com
Content-Length: 11
Connection: Keep-Alive
status=blah
The response that I get back from twitter for this second request is as follows:
HTTP/1.1 401 Unauthorized
Date: Fri, 05 Mar 2010 16:17:18 GMT
Server: hi
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
Content-Type: application/xml; charset=utf-8
Content-Length: 135
Cache-Control: no-cache, max-age=1800
Set-Cookie: guest_id=12672352252251; path=/
Set-Cookie: _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGsdgsdhdrhvdrthvdthd0%250ANDdkZTEyZjczZTY3ZGE4YmQ5IgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--0eb657ba0esdrvthdtdtgcdrtgc0ece8f1460; domain=.twitter.com; path=/
Expires: Fri, 05 Mar 2010 16:47:17 GMT
Vary: Accept-Encoding
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<hash>
<request>/1/statuses/update.xml</request>
<error>Incorrect signature</error>
</hash>
Any idea what could be going wrong?
Note, the OAuth tokens and stuff have been scrambled of course.
Solved:
Even though I had to make this call a POST request, the actual parameters couldn't be in the POST body. I put the status variable in the query string on the request and it worked fine.
i got similar problem ...401 unauthorized ...using php
i was following the examples in
http://www.snipe.net/2009/07/writing-your-first-twitter-application-with-oauth/
until i discovered the parameters 'POST' and $data
was swapped in the line
$content = $to->OAuthRequest('https://twitter.com/statuses/update.xml','POST',$data);
maybe it is your case too?
maybe not anyway i found that tutorial very useful
cheer
POST parameters are fed into the hash that produces the signature, so you have to make sure they are included when you calculate it.