Normally both calls are shown, the pre-flight and the actual request. This is sometimes annoying. Is there a way to hide the pre-flights requests ?
Or is there a plugin to filter certain requests based on headers ?
The quickest way to do this is to filter on -method:OPTIONS.
Explanation: all pre-flight requests are via the HTTP OPTIONS method (opposed to POST or GET). This filter says "not method OPTIONS".
Note the leading hyphen because if you forget it, you'll only show pre-flight requests.
By default "All" requests will be displayed in network tab. To see OPTIONS requests, you can select "Other". To see only your web api requests, you can select "XHR" (which wont show OPTIONS request).
Related
I'm working with an API that doesn't yet have CORS setup. So, instead of waiting until that's setup, I thought I could use fiddler to add the Access-Control-Allow-Origin header to the responses coming from the server. I haven't used fiddler for a while and can't figure out how to add headers to the response. Is this not supported in the free version of fiddler-everywhere?
It's not ideal, but I found a workaround. After the requests have gone off once, I right-click the ones I'm interested in and select "Add new rule". The rule will automatically do an exact match to the URL and sets the action of "Return manually crafted response" If I edit the rule, the header can be added in the raw text.
When the URL entered into the Chrome address bar results in the Save As dialog being popped (Content Type is not recognised), the network request never appears in the network tab in dev tools.
Is there a way I can track this to see the response headers from within Chrome, ie. without resorting to external tools like tcpdump or fiddler?
Yes, it's possible to access the request/response data in a more raw form using the network internals interface provided in Chrome. Navigate to chrome://net-internals/ (can't make it a link)
Click on the 'Events' links to see the recent requests and active sockets. I recommend using the filter at the top to remove some of the noise.
Select the relevant entry corresponding to the source type URL_REQUEST.
On the right hand side, you will see a whole load of data, but the request headers will appear under the HTTP_TRANSACTION_SEND_REQUEST_HEADERS section, and the response headers will appear under the HTTP_TRANSACTION_READ_RESPONSE_HEADERS section.
The following is an example from a simple Node server I set up to return a response with the 'Content-Type': 'application/octet-stream'} header. This forces the browser to download.
I am developing a project which can disable a particular REST URI at runtime so that consumers will get an error. I have created interface/controller for disabling a URI. But I can not figure out how to disable it.
I thought of setting disable flag for the URI and sending blank data, but consumer needs to see an error.
I can not use Response every where.
Need Help
Implement a ContainerRequestFilter(more on filters), which when a specific criteria is met will call:
ContainerRequestContext.abortWith(javax.ws.rs.core.Response)
with a proper HTTP status code.
I have a web service that runs a SQL query, sorted by one of several columns, and returns a single requested page (as in skip M limit N). The UI in front of it follows a 'load more' pattern, accumulating all loaded pages of results in one view.
The problem is new and deleted records, which can happen at any time, causing the result of a 'load more' to be wrongly aligned, and depending on the sort being used, even obscuring new records that should be shown. In addition to an automatic refresh on a timer in the frontend, I'm going to add a timestamp field to the RESTful request and response format to allow the webapp to detect that the view should be completely reloaded on a 'load more' call.
My question is, what HTTP status code is a best fit for this signal? In reviewing the codes I don't see an exact fit. I thought of using 302 Found with a link to 'page 1', but I wonder if that might cause unwanted caching of the redirect. I also thought of 400 Bad Request, but there's nothing actually wrong with the request, it's just the data needs to be reloaded.
Pages are served from a POST /path call where the requested page is provided in a JSON body.
I'm not a complete purist, so anything that would make it work without caching or other side effects is acceptable, but I would like to adhere to REST principles as much as possible.
anything that would make it work without caching or other side effects is acceptable
Responses to POST requests are not cacheable unless you explicitly mark them as such. So you can use any combination of status code, response headers and response entity to communicate the “please reload” message to the client.
You can use conditional requests. Include your client’s timestamp in the If-Unmodified-Since header. Respond with 412 Precondition Failed if client is stale. The client will have to know how to reload.
You can try 307 Temporary Redirect, but only if you encode pagination in /path, because upon receiving 307, (I’m assuming you’re doing AJAX here) XMLHttpRequest will transparently re-submit the same POST request to the new Location (at least this is what my Chromium does). Your actual page JSON will have to include metainformation on the range it covers, so that the client knows it has to replace the rows, not append them.
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm