I use your IT Hit WebDAV server and I try to send 'failed' response on delete request to Mini-Redirector (Microsoft WebDAV client). I checked all available 'failed response' (401, 402, 423) and I see that Mini-Redirector ignores it (file/directory is deleted and restored on refresh).
Do you know how it should be handled to prevent delete file/directory on Mini-Redirector side?
As far as we know Mini-Redirector's reaction to response codes is undocumented. From our experience it just ignores any response codes.
Related
Does/should server code run when the server return status code 304?
I understand that the server should not return anything (client should use the cache), but I cant find any info on whether the server will executed the code in an api endpoint for example.
RFC 2616 section 10.3.5 describes the 304 Not Modified response:
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a message-body
The server will send Date, ETag and/or Content-Location (200 only), or Expires, Cache-Control, and/or Vary if the respond may vary.
What is a Conditional GET?
An cliet application, browser, or proxy with a retained Last-Modified or Etag value will issue a Conditional GET as an initial header only. This allows the client to determine if the resource has been updated.
How does the client know if the resource changed?
Well it depends on how the server is configured.
The Origin Server May:
Ignore caching, serve every request new.
Similar to ignoring, you may develop the application to change query strings. This prevents caching at Proxy Servers and invalidates the client cache.
If configured to do so, issue a Last-Modified or Etag value. Often done for static content. Proxy Servers and Client Caches use to invalidate their version.
A Web application could issue a Last-Modified far
into the future then change the URL to invalidate stale content. This requires the application be developed with this feature in mind.
Resources may also be issued version numbers. This allows them to preserve Proxy Caches but invalidate Client Caches.
Does server code run when the server return status code 304?
Almost Never. Disregarding that it is technically possible for an incorrectly configured application to respond with a 304 Not Modified code instead of a 200 code.
With a ETag and/or Content-Location value, a server (nginx for example) can confirm nothing has changed without issued a call to the application. This also neatly handles resources with version numbers the same way.
For query strings (image.jpg?version=12), the client cache will invalidate the content. A Proxy Server will also invalidate, and the query will be requested fresh.
I understand that the server should not return anything (client should use the cache), but I cant find any info on whether the server will executed the code in an api endpoint for example.
I'm a fan of nginx, here is a good resource on how caching applies to it.
In short, as much as you can do to support various caches between your client and the application the more requests you can support per day.
We have multiple clients running worldwide. Connecting the nearest respective server as per country preference.
Now my primary requirement is, independent on client and server, with the help of networking information (logged in Wireshark), is it possible to retrieve HTTP status code.
For example, 404 Not Found if nothing available at the server-side.
I want to prompt error codes to the client indicating the reason for the disconnection.
If you've already captured HTTP data on Wireshark you can just use the following filter to catch all response codes:
http.response.code == 404
For all response codes regardless:
http.response.code
Yes. You can open the .pcapng file and then
• Click on “Statistics”
• Select “HTTP”
• Select “Packet Counter“
In my case, I can 14 requests and 14 responses. (Success 2xx).
I build a service worker which always responds with data from the cache and then, in the background, sends a request to the server. If the server responds with HTTP 304 - not modified everything is fine, if the server responds with HTTP 200, that means the data was changed and the new file is put into the cache, also the user is notified and asked for a page refresh.
I use the not-modified-since / last-modified headers to make sure the client gets the most up-to-date version. When a request is sent via fetch() the request passes the HTTP-cache on it's way to the network - also the response passes the HTTP cache when it arrives on the client. The problem is when the response has the status 304 - not modified the HTTP cache responds to the service worker with the cached version and replaces the status with 200 (as it is described in the fetch specification - HTTP-network-or-cache-fetch). In the service worker there is no possibility to find out whether the 200 response was initially sent by the server (the user needs to be updated) or it was sent by the cache and the server originally responded with 304 (most up-to-date version is already loaded).
There is the cache-mode flag which can be set to no-cache, but this bypasses the HTTP-cache also when the request is sent to the server, which means that the if-modified-since header is not set and the server has no chance to find out which version the client has. Also this flag is only supported by firefox nightly right now.
I think the best solution is to set a custom HTTP header like x-was-modified when the server responds with 200. This custom header can be accessed in the service worker and can be used to find out whether a resource was updated or not - even if the HTTP cache replaces the 304 status with 200.
Is this a legit solution/workaround? Are there any suggested approaches to solve this problem?
Should I even rely on HTTP headers which are supposed to handle the HTTP cache when implementing the service worker cache? Or should I rather use custom x-if-modified-since / x-last-modified headers and use indexedDB to store the information on the client and append it to each request?
Why does fetch() even replace the 304 code with 200 if there is a up-to-date version in the cache?
You can’t rely on the status code (304 vs. 200) to determine whether something has changed. What if some other part of your code requests the same resource, thus updating the browser’s cache?
Instead, simply compare the response’s Last-Modified header to what you sent in If-Modified-Since, or whatever you last saw in Last-Modified. If the values don’t match, something has changed.
For more precision (if the data can change several times in 1 second), consider using ETag instead of Last-Modified.
Why does fetch() even replace the 304 code with 200 if there is a up-to-date version in the cache?
Because usually people just want to get fresh content, regardless of where it comes from. A 304 response is only interesting to those who implement their own HTTP caches.
I have a resources with uri /api/books/122 , if this resource doesn't exist at the point where a client sends HTTP Delete for this resource, what is the appropriate response code from this action? Is it 404 Not Found?
Thanks
The response code for a delete call can be any of the following :
DELETE /api/book/122 - The server successfully processed the request, but is not returning any content
204 No Content
DELETE /api/book/122 - Resource does not exist
404 Not Found
DELETE /api/book/122 - Resource already deleted
410 Gone
DELETE /api/book/122 - Users does not have permission
403 Forbidden
DELETE /api/book/122 - Method Not Allowed
405 Method Not Allowed
DELETE /api/book/122 - Conflict (User can resolve the conflict and delete)
409 Conflict
In your case 404 is apt.
Yes, it would be 404.
In general it will be a 400 series error if the request is wrong somehow, and a 500 series error if something goes awry on the server.
I would suggest taking a look at this flow diagram. It's obviously a little bit more than you need but a great resource for future readers. Sadly there is no excerpt possible.
http-decision-diagram
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