I'm trying to retrieve Set-Cookie from response header I send using MSXML2.XMLHTTP.6.0.
But the response header doesn't include this type. Just standard ones like Agent, Server, Accept etc.
When I monitor network it is being sent.
I cannot use WinHttp.WinHttpRequest.5.1 because it says 'No credentials were available in the client certificate' even if I sent one with the request.
Can anyone help me with that?
Related
I am confused by why the cors package allows the request to be processed even if the origin in the request header isn't white-listed. For example, res.status(202).send(await User.find()) returns a response with status code 202, but the data can't be loaded in the Chrome console.
Also, doesn't the browser send preflight OPTIONS requests to know what's allowed; why would it send cookies/credentials along a request with a disallowed origin?
Edit: Tried a post request on jsfiddle and the post request doesn't happen server side. When I said "why the cors package allows" it would be better to say why the browser allows.
CORS is enforced in the browser, not in your server. The server participates in setting headers that the browser can then use to determine whether the request should be allowed or not. But, it is the browser that ultimately decides whether the CORS request satisfies the requirements or not and the result should be passed through to the Javascript in the browser.
Thus, the request is sent to the server, response is received and THEN the browser decides whether the Javascript in the page is allowed to see the result or not.
In some cases where the request is likely to have side effects on the server (based on a set of criteria in the request), the browser will send a pre-flight request to get just the CORS info first.
IntelliJ has an HTTP client. When composing a file that is interpreted by the HTTP client, you can specify headers that go out to the server with the request, like so:
###
GET https://{{hostname}}/{{path}}
Content-Type: application/json
X-Auth-Token: {{x-token}}
I want to find the actual value of the token that was used to replace the variable name, seen above as {{x-token}}, but I don't see any way to obtain the request headers. The response headers are obviously available, but not the request headers. See the image below for the test results that are shown after running the HTTP client inside Intellij:
Is there a way to display the REQUEST headers?
Link to IntelliJ Documentation - HTTP Client -- the documentation seems to never mention the actual request headers that are sent over the wire, but they do discuss how to define request headers in composing the .http file type.
Check the Tools | HTTP Client | 'Show HHTP Requests History' action.
In Azure Data Factory V2, I created a new http dataset an added a url and basic login details to connect to a https endpoint, when use the the Test Connection the response is "Connection successful"
When i try to "Preview data" it fails, the message from more is
The credential to read http file is invalid. Activity ID:89ae4de1-e6be-46fd-abb9-39360fe5323b.
How do i find out more about this error?
When I try the same url and basic login details in Postman I get back the expected results.
thanks
In Azure data factory, if basic auth type is specified, the http connector honor basic auth protocol, that means：
* It would send out a request without any credential first
* when the http server return 401 response with correct WWW-Authenticate header, it will continue enclose credential into next http request
So if your http server can't handle the request, you will get unauthorize error.
Postman can do it because postman ignored the first http request and send out the second one directly.
you can manually add header to your request:
Authorization: Basic ......
If you don't know how to generate it, you can copy it from postman, after passing credentials.
Best,
Pawel
Does anyone know how to get access to request HTTP headers within MessageEncoder.ReadMessage method?
It seems that WCF already "knows" request headers at the point of invoking ReadMessage method, at least Content-Type and Content-Length but I cannot get the access to the Content-Encoding header.
Basically, I'm trying to utilize gzip de/compression for WCF service (http://msdn.microsoft.com/en-us/library/ms751458.aspx) and would like to check if decompression is necessary for incoming request. To do that I'd like to check Content-Encoding header but cannot figure out where to get it.
Any ideas?
Thanks!
Here's an answer I gave in another thread which explains how you would need to manipulate the headers via the WebOperationContext in another IOperationBehavior which is coupled with the MessageEncoder.
I have the following code that creates a serverside object of the xmlhttp class. I am trying to connect to a site that requires basic authentication. I am able to get this to work with the code below.
What's the problem? Well I'm passing the credentials using the open call. That alone is not enough. I must also set the authorization header with the manually calculated base64 encoded username:password combination. If I try to set the header without passing the credentials to the open call, it fails. Call me crazy, but when I pass the credentials to the open, that's all I should have to do. If I set the header, that's all I should have to do. Right? Doing both seems like something isn't right. Right?
Is this a bug or a glitch?
Additional background is:
IIS 5 & ASP Classic
The error received when one of the two items is ommitted is an HTTP Status 401:
"You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept."
Since IIS is making the request I'm not able to inspect it with Fiddler :-(
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
xmlhttp.setTimeouts 5000, 5000, 10000, 10000 'ms - resolve, connect, send, receive
xmlhttp.open "GET", "http://example.com/", False, "username", "password"
xmlhttp.setRequestHeader "Authorization", "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
xmlhttp.send
I believe you're hitting this known limitation (or bug) that can be boiled down to msxml2 lacking (or having incorrect) support for "negotiated" authentication mechanisms, which means you have to force the issue (bypass the incorrectly-conducted negotiation) exactly by adding the authorization header yourself as you're doing.