I have a client that issues an HTTP PUT to upload a file to a SharePoint server. This server requires authentication (NTLM or Negotiate). The client includes an "Expect: 100-Continue" header in the PUT request.
When I PUT the file to SharePoint2010 (IIS 7.5), the server immediately responds with a 401 error as soon as it receives the header. This allow the client to begin the authentication process without unnecessarily uploading the entire file.
When I PUT the file to SharePoint2013 (IIS 8.0), the server immediately responds with a 100-Continue. However, once the client has uploaded the file in the body of the request, it replies with a 401. This means that the client has uploaded the entire file just to receive an authentication error. The server should have been able to respond with the 401 prior to the client uploading all of the data, as IIS 7.5 does.
Is this change in behavior inherent in IIS8? Is there a configuration option that controls this? Is there something I can tweak in the header to change the server's behavior?
You must remove the expect: 100-Continue from your HTTP Header
This link will be usefull if you use .NET :
Removing the expect http header
Related
I'm trying to retrieve 3 response headers (Rails Devise Auth Headers: uid, client, access-token) in every request to a Rails Server.
Using Postman (http client) it's working.
With OkHttp (java http client) the headers just don't show up in the client (i've checked using Wireshark).
When i'm in debug mode it just work...
The additional headers with postman are due to postman sending an Origin header and the server is replying with CORS headers, i.e. Access-Control-.... These headers are send within the normal HTTP header, i.e. not after the response.
But these access control headers are only relevant when the access is done from a browser because they control the cross origin behavior of XHR. Since you are not inside a browser they should be irrelevant for what you are doing. What is relevant are the body of the response and some of the other headers and here you'll find no differences. Also irrelevant should be if multiple requests are send within the same TCP connection (HTTP keep-alive done by postman) or with multiple connections (OkHttp) because each request is independent from the other and using the same TCP connection is only a performance optimization.
If you really want to get these special headers you should add an Origin header within you OkHttp request. See the OkHttp examples on how to add your own headers. But like I said: these access control headers should be irrelevant for the real task and there should be no need to get to these headers.
There is a property "config.batch_request_buffer_throttle" in the file "config/initializers/devise_token_auth.rb" of the Rails Project. We changed it from 5 seconds to 0 seconds.
It is a property to keep the current token available for that amount of time to the following requests.
As the original documentation: "Sometimes it's necessary to make several requests to the API at the same time. In this case, each request in the batch will need to share the same auth token. This setting determines how far apart the requests can be while still using the same auth token."
So when we did the request using Postman or in Java Debug the 5 seconds was running allowing Devise to generate new tokens then retrieve them to the client.
I have a web server which contains an API to upload files to Amazon's S3 storage. Since I do not want to waste resources on streaming the files through my server, when an upload request comes in, I generate a pre-signed URL for the client and then redirect that client to this URL using HTTP 307 - Temporary redirect.
In practice, the flow looks like this:
Client issues a PUT request to my server, requesting a file upload
My server inspects the request and generates a pre-signed URL for S3
My server responds to client with 307 redirection to the pre-signed URL
Client repeats the PUT request to the pre-signed URL
Upload commences
The challenge
My server uses the Authorization header for... well, authorisation. Incidentally, Amazon also accepts this header for authorisation, although the values expected by both parties are completely different.
The problem is, that since my upload API requires this header to be present during file upload request, when my server issues the 307 redirect back to the client, the client takes all the headers in the original request and sends them along to the pre-signed S3 URL, which causes the request to be rejected by Amazon due to authorisation error.
The question
Can I somehow instruct the client (via HTTP response header) to not include the Authorization header when following the redirection?
Current solution
Right now we "fixed" this by returning the pre-signed URL to the client in the response body. The client then manually issues a new PUT request to that URL without the Authorization header. This works fine. I would like to know if there is a way to achieve this behaviour without this extra manual work.
What is the client? In the above statements, when I mention the "client", right now it could be either a modern web browser or a native iOS or Android app. On iOS, we use Alamofire for HTTP communication. I am unsure of what library or components are used on Android.
Note: I have seen this question and its answers, but it does not contain the answers I seek.
I have a TXT file, stored in a subfolder on my web site, and our Windows application reads this file through HTTP.
Our application just sends a request with minimum headers: HTTP verb, filename, protocol on first line and Host key to point the server. Web server (which is a shared hosting) returns 500 to this request, where it returns 200 to request populated by browser.
Using Fiddler, I added User-Agent header info to request and voila, it returned 200. Regardless of what the value is.
Now, we'll add this user-agent info into our application, but it takes time to update all clients. Hosting staff say they did not make any changes on server settings.
Is there any solution that I can apply using web.config?
Regards,
I have an ASP.NET form (a login page), when I POST the values to the server, the request passes through a proxy and the POST pareameters end up getting lost and ultimately the page just refreshes as there are no POST parameters.
The thing is that this is not a constant issue as sometimes you can log in fine and generally if you clear your browser temp files it then works ok.
I ran Fiddler to check what's going on and basically I'm getting:
A regular POST request containing session id, POST data etc. The response (HTTP 407) contains a Proxy-Authenticate: Negotiate and Proxy-Support: Session-Based-Authentication header
The next request to the server contains a Proxy-Authorization: Negotiate header containing a long string (base64 i think). This request does NOT contain the POST values. The response is another 407 and actually now that i look at it Fiddler displays 'HTTP/1.1 407 Proxy Authentication Required ( Access is denied. )' as the header.
Then there's a third request that contains the Proxy-Authorization header and returns 200 OK, but of course the POST values weren't sent
Subsequent requests result in a HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. ) response followed by a second successful but empty request.
The client wont let me bypass the proxy as it's intermittent and all other pages in the application (that include plenty of web forms) work fine.
Any ideas on what I can try?
I want the IIS server to return HTTP 304 (Not Modified) when a particular file is accessed.
How can I set this up?
Check the "Enable Content Expiration" box on the HTTP Headers tab in IIS Manager:
IIS 6.0 F1: Web Site Properties - HTTP Headers Tab
AFAIK, it isn't possible to do this (in IIS). There are a few criteria that have to be met for this code to be sent out:
Client must have cached copy of page.
The request's If-Modified-Since HTTP Header Time/date stamp must match what's on the server.
If both of those conditions are true, the server will return a HTTP 304 status code.