So I am using UnityWebRequest to call server that return 3 Set-Cookie headers. When calling method GetResponseHeaders (https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequest.GetResponseHeaders.html) I can only see the first one, second and third are missing.
set-cookie: wp_woocommerce_session_some bla; expires=Thu, 04-Oct-2018
08:29:58 GMT; Max-Age=166371; path=/
set-cookie: wordpress_logged_in_some more bla; path=/; secure; HttpOnly
set-cookie: woocommerce_items_in_cart=1; path=/
Is that known unity issue, anyone found a way around it? This topic here thought might be helpful - Retrieving multiple "Set-Cookie" headers from a HttpWebResponse. Unfortunately I am unable to implement Cookie Container in unity3d.
Any help would be appreciated.
Related
I heard that wolkenkit also offers a REST API but didn't find any documentation for that. I sifted through the sources and found some indications on how to do this.
I am using HTTPie for doing requests from the cli:
$ http post https://local.wolkenkit.io:3500/v1/read/lists/labels
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate
Connection: keep-alive
Date: Wed, 30 Aug 2017 21:08:07 GMT
Expires: 0
Pragma: no-cache
Surrogate-Control: no-store
X-FRAME-OPTIONS: DENY
X-Powered-By: Express
X-XSS-Protection: 1; mode=block
content-type: application/json
transfer-encoding: chunked
{"name":"heartbeat"}
{"label":"first","id":"baa1b2b6-ab85-4929-a488-0cae622de20a","isAuthorized":{"owner":"anonymous","forAuthenticated":false,"forPublic":true}}
{"label":"second","id":"7fc6c3c9-3285-4292-b3db-6d88ca90a347","isAuthorized":{"owner":"anonymous","forAuthenticated":false,"forPublic":true}}
I have two entries in my label readModel, but there appears to be a third one {"name":"heartbeat"}. Where does that come from and what does it mean?
Is this a bug or may i have created that entry accidentally?
Disclaimer: I am one of the developers of wolkenkit.
This is actually neither a bug, nor did you create the entry accidentally ;-)
Under the hood we stream JSON over HTTP, and we had the experience that some proxy servers (and similar things) caused issues when there were long pauses between two data packets.
In the past we changed the way how the read model is being delivered a few times, and I don't think that this is really still required, so this is a holdover from the past. (If we were talking about the events route, the story would be different, here it is definitely still needed.)
In the library that we use under the hood, json-lines-client, we filter out the heartbeat events:
const isNotHeartbeat = function (data) {
const keys = Object.keys(data);
return !(
(keys.length === 1) &&
(keys[0] === 'name') &&
(data.name === 'heartbeat')
);
};
(Taken from the source code of json-lines-client 0.7.9)
For the moment, I'd suggest to introduce a similar logic to your code, so that you simply ignore these events (there may be more than one over time, and they do not need to be the first one).
I don't see any way to get that header in akk-http. That header is removed from header list in HttpResponse.
I know there are methods that return the contentLength from entity:
HttpEntity.contentLengthOption
and
HttpEntity.contentLength on strict entity.
But that both calls are based on entity itself, and that's not what I want.
In my case I'm sending the Head request to server(riak) to check if the object has proper size. I don't want to get the whole object using Get. That should be just a test.
That's how the response looks like:
curl -I "http://req-to-riak"
HTTP/1.1 200 OK
X-Riak-Vclock: a85hYGBgzGDKBVI82eqS92f/Ot/EwOT3PoMpkTGPleHKa8WLfFkA
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.10.8 (that head fake, tho)
Last-Modified: Fri, 12 Aug 2016 06:42:28 GMT
ETag: "5IVrr7tsZp1O4FHLnMSc30"
Date: Wed, 24 Aug 2016 12:53:32 GMT
Content-Type: image/gif
Content-Length: 290305
But akka still return 0
It's a bug of Akka-Http, see here: https://github.com/akka/akka-http/issues/377
I'm trying to set up a small Silex RESTFul server, and now I'm playing around with HTTP Headers.
One GET function checks If-Modified-Since header, and compares with database's Last-Modified item.
Here's a small code sample:
if($hasModifications){
$response = [items]
$statusCode = 200;
} else {
$response = ['result'=>'no modifications'];
$statusCode = 304;
}
return $app->json($response,$statusCode,$headers);
Whenever $statuscode!=200, I only get a blank page and also no custom header gets sent. This also breaks CORS because I can't set Access-Control-Allow-Origin header.
Should I be doing it some other way?
(PS: this is not the actual code, and also if I replace $statusCode for 200, then everything works back as normal)
Update:
So far, I guess from what I've been reading, that 304 statuses shouldn't send anything on response's body. But what about headers? If I don't comply with CORS, then the AngularJS Frontend will fail and I wouldn't be able to catch the "Not Modified" exception!.
Obviously, I can figure it out some other way. But it would be nice if I could have both things working properly (REST+CORS)!
Update 2:
var_dump($headers)
array(4) {
["Last-Modified"]=> string(29) "Fri, 21 Aug 2015 22:47:53 GMT"
["X-Status-Code"]=> int(304)
["Cache-Control"]=> string(25) "post-check=0, pre-check=0"
["Pragma"]=> string(8) "no-cache"
}
Notice that I'm using X-Status-Code to inform the true HTTP Status.
Right now, the response line of code goes as follows:
return $app->json($response,200,$headers);
If I changed 200 to 304, I can't see the output of var_dump (gives me an empty page). Also if I set 304 status with no header parameter, it is still the same.
Seems like return or $app->json clears the HeaderBag, since I'm using JDesrosiers\Silex\Provider\CorsServiceProvider(), and those headers parameters also get cleared.
This is the Raw HTTP Response taken from Firefox with Status Code 304:
Cache-Control: post-check=0, pre-check=0, private
Connection: Keep-Alive
Date: Sat, 22 Aug 2015 19:52:18 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.7 (Ubuntu)
And this, with Status Code 200:
Cache-Control: post-check=0, pre-check=0, private
Connection: Keep-Alive
Content-Length: 25
Content-Type: application/json
Date: Sat, 22 Aug 2015 19:53:12 GMT
Keep-Alive: timeout=5, max=100
Last-Modified: Fri, 21 Aug 2015 22:47:53 GMT
Pragma: no-cache
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.11
X-Status-Code: 304
Apache strips out CORS headers on 304 status codes.
You can read more in issue #51223 and you can also find a patch which will fix this problem.
If you don't want or you can't recompile Apache, you could try running Nginx, which will leave the CORS headers in place.
I'm asking an advice on how to proceed to report the following bug:
* I'm describing the bug as using 'private browsing' because it was how I could reliable reproduce it; the actual problem happens whenever the browser has a pure cold cache, like when cookies and everything is cleaned, for example
Start any browser in 'private browsing' mode, go (w/ cold cache) to any 'like button' URL, e.g.
https://www.facebook.com/plugins/like.php?href=https://www.facebook.com/BatePapoUOL&send=false&layout=button_count&width=450&show_faces=false&action=like&colorscheme=light&font=arial&height=21
after clicking 'like', the page goes blank and some network error is logged on firebug's (and the like) network page.
The response header is the following (please note that its content-lenght is zero):
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=0
X-Content-Type-Options: nosniff
X-WebKit-CSP: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net;
X-XSS-Protection: 1; mode=block
Content-Type: text/html; charset=utf-8
X-FB-Debug: P5P8mjHfEje2BZgxUL+/gi9dj8+wrPR0zMMSlwrdAAo=
Date: Mon, 07 Jan 2013 19:08:53 GMT
Connection: keep-alive
Content-Length: 0
I also tried to get a new code for my like button done # this URL to no avail:
https://developers.facebook.com/docs/reference/plugins/like/
The issue is being addressed by Facebook. More information available here
https://developers.facebook.com/bugs/403206233093888
I'm writing a scraper using Curl and I found that a lot of pages include multiple redirecting headers, like:
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.0.4
Date: Thu, 17 Nov 2011 17:46:35 GMT
Transfer-Encoding: chunked
Location: http://secure.domain.net/track/NDg6MTE6MTU/?autocamp=TJ_ABC_VA_A02
HTTP/1.1 302 Found
Date: Thu, 17 Nov 2011 17:46:37 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: nats_cookie=Bookmark; expires=Fri, 18-Nov-2011 17:46:37 GMT; path=/; domain=domain.net
Set-Cookie: nats=MjYwNjk6MTE6MTU%2C0%2C0%2C0%2C0; expires=Sun, 27-Nov-2011 17:46:37 GMT; path=/; domain=domain.net
Set-Cookie: nats_sess=00e48c685c9acbb37fcc3b7461b1ab81; expires=Sat, 25-Feb-2012 17:46:37 GMT; path=/; domain=domain.net
Location: http://www.domain.net/tour/?nats=MjYwNjk6MTE6MTU,0,0,0,0&autocamp=TJ_ABC_VA_A02
Transfer-Encoding: chunked
Content-Type: text/html
HTTP/1.1 200 OK
Date: Thu, 17 Nov 2011 17:46:39 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: text/html
As you can see there are two headers with the "Location:" directive.
I'm just wondering why they do this.
Wouldn't be enough to include only one header?
The redirecting URLs are even different,
So which one is the "real" landing page?
Thanks.
When CURLOPT_FOLLOWLOCATION and CURLOPT_HEADER are both true and redirect/s have happened, the response returned by curl_exec() will contain all the headers in the redirect chain in the order they were encountered.
Source:
http://php.net/manual/en/function.curl-setopt.php#103232
In addition, if a response body is returned anywhere in the redirect chain, it will also be included in the return value of curl_exec().
So you can receive something like:
HEADER 1
HEADER 2
BODY 2
or
HEADER 1
HEADER 2
BODY 2
HEADER 3
BODY 3
Take note of this in case you only want the response header and body from the last redirect. You need to manually strip the headers and bodies from previous redirects.
You're looking at three different requests, each of which has its own set of headers. The first URL redirects to the second and the second redirects to a third. Your browser has to download three pages to get the final content of the landing page. Why do they do this? Disregard for the extra latency this adds to the user experience, mainly. Based on the URLs, this is for some kind of user tracking or statistics purpose, and it's likely easier for them to force the browser all over their site than it is to return the content directly.