We have a tileserver that can respond with 429 status code if the user has consumed all its quotas.
In my client app, I'd like to show a modal saying to the user it has consumed all its quotas. How can I intercept http responses from tileserver and check status code for requests issued by mapbox-gl-js ?
I tried with the error map event, but there are no information on status code.
Thanks,
Nicolas
Related
We have 2 Windows services (same machine) that communicate on top of HTTP Protocol.
On specific machine we see the HTTP POST being sent from the client (Windows service) and arrives to the server (Windows service listening to REST CALLs) - 2 times, meaning i get 2 exact HTTP Post request on the service, but we see on client it was executed only 1 time.
Before going to wireshark/analyze the HTTP protocol, I wish to understand what explain this behavior.
When going to https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
"the origin server SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created"
I guess we should look in wireshark for 201 response? And if no response? Does the HTTP or network framework for my C# application is retrying the POST on the server side? because we dont see 2 requests sent from client code.
POST reply behavior
While true, more often than not the server replies with a 200-ok status code and some extra information.
Whether this is by mistake or to avoid chatty apis or some other architecture/design consideration, only the developer can tell.
So in theory you get a 201 with an identifier and then make a GET request with said identifier to retrieve details.
In practice a lot of times this does not occur. So it is not safe to assume this behavior.
Your problem
I highly doubt that there is a built in mechanism that retries post. There are plenty of reasons for that:
Duplicating entries. Imagine creating a PayPal payment. If the network has an error and you just did not receive the answer, the built in mechanism will charge you twice.
There are libraries that do that only when you are sure that the request is idempotent, that is the post contained some sort of identifier and the second request will fail.
First, the calls are HTTP GET (not POST).
We define the URL with hostname/FQDN, the solution to avoid duplicated calls was to work with ip address instead of hostname when sending the Rest API.
This is the long explanation of the problem, no root cause yet.
Used both Wireshark/Process Monitor to diag, not sure for the root cause.
Process Monitor: Filtering to display network calls
Wireshark: Filter to show only HTTP
The Client send a single HTTP Get request to:
/DLEManagement/API/Engine/RunLearningPeriod
The call was executed at 11:08:16.931906
We can see 2nd call at 11:08:54.511909 - We did not trigger.
HTTP Get executed from *Server.exe (in red) and the Server is at *Management.Webservice.exe (in red).
We see that a *Client.exe (Antivirus process, in blue) is sending TCPCopy packets in the window between we sent and received.
Also, we can see that the first request was made with APIPA IPv6 and the 2nd call is IPv4, We checked the network interface and it was disabled.
Wireshark screenshot:
Process Monitor screenshot:
Network configuration:
I need to create some kind of health check in Splunk that calls a Rest URL every hour and check if the response returns HTTP code 200 and send an alert in case there is an error like http code 400 or http code 500.
For example Splunk should make an http call to the URL of my application every hour and check if the URL of my application returns HTTP code 200. In case the response from the URL has a different code than 200 then send a notification email telling that something is wrong.
is that possible?
Please help.
Check out the REST API Modular Input app at https://splunkbase.splunk.com/app/1546/.
You can also create a Python program that checks the URL and reports on its health. Schedule that program as a scripted input.
You can use the website monitoring app for Splunk, https://splunkbase.splunk.com/app/1493/ to get the return codes for your endpoints
I develop simple application for fetching data in SharePoint sites. I use requests from SharePoint REST API for getting SharePoint Sites info (both for Team Sites and Communication Sites). Also I use such API for getting info about files and folders in SharePoint document libraries.
Sometimes I get throttling responses from Microsoft with 429 HTTP code and
"429 TOO MANY REQUESTS" message in reply body.
But recently I noticed strange behavior: "429 TOO MANY REQUESTS" message returned in reply body but HTTP status code is 401 (which status for UNAUTHORIZED request). However I handle 401 HTTP status code in different way and this totally break the logic of my service and 401 HTTP status code in general.
I think it's not normal behavior, is it? How can I determine if 401 HTTP status code states for throttling of for unauthorized request? Straightforward reply body parsing is not a good approach as I think.
We're getting some HTTP responses with status 200 but with incomplete content (cut off at a different position in each request).
I wonder if there's something wrong with that network or if this kind of response errors must be expected and dealt by our application, i.e. if HTTP clients must check if the response content is complete. I haven't seen this behavior before.
More information:
The issue happens in a place where they have WiFi. If the client, the app, uses the mobile network, the response is always complete. We suspect that there's something wrong with that WiFi because we have not detected this issue in other places (other WiFis). The problem is not caused by the client since I could also reproduce it using Postman.
I made several tests at that place (using the app and also Postman) and found that on mobile data the response always comes OK, but when connecting to that WiFi the response sometimes gets truncated. Also, I saw that other API requests get the response correctly, even when the content length is 10 times bigger (I thought that maybe the response was too big, but we're talking about only 10Kb).
The failing request is a regular HTTP POST request using JSON and sent to our REST API made with Dropwizard and hosted on Heroku. The request gets processed correctly on the server, which returns status 200 and the content. The client gets the status 200 but the content is truncated, so the whole operation can't be finished successfully.
I'm trying to upload a file onto my personal server.
I've written a small php page that works flawlessy so far.
The little weird thing is the fact that I generate all the body of the HTTP message I'm going to send (let's say that amounts to ~4 mb) and then I send the request to my server.
The server, then, asks for an HTTP challenge and my delegate connection:didReceiveAuthenticationChallenge:challenge replies to the server with the proper credentials and the data.
But, what's happened? The data has been sent twice!
In fact I've noticed that when I added the progressbar.. the apps sends the data (4mb), the server asks for authentication, the apps re-sends the data with the authentication (another 4mb). So, at the end, I've sent 8mb. That's wrong.
I started googling and searching for a solution but I can't figure out how to fix this.
The case scenarios are two (my guess):
Share the realm for the whole session (a minimal HTTP request, then challenge, then data)
Use the synchronized way to perform an HTTP connection (things that I do not want to do since it seems an ugly way to handle this kind of stuff to me)
Thank you
You've run into a flaw into the http protocol: you have to send all the data before getting the response with the auth challenge (when you send a request with no credentials). You can try doing a small round trip as the first request in the same session (as you've mentioned), like a HEAD request, then future requests will share the same nonce.
Too late to answer the original requester, but in time if somebody else read this.
TL;DR: Section 8.2.3 of RFC 2616 describes the 100 Continue status which is all what you need (were needing) in such a situation.
Also have a look at sections 10.1.1 and 14.20.
The client sends a request with an "Expect: 100-continue" header, pausing the request before sending the body. The server uses the already received headers to make its decision whether this request may be accepted or not (if the entity –the body– to be received is not too large, if the user's credentials are correct...). If the request is acceptable for the server, it replies with a "100 Continue" status code, the client sends the body and the server replies with the final status code for that request. To the contrary, if the request is not acceptable, the server replies with a 4xx status code ("413 Request Entity Too Large" if the provided body size is... too large, or a "401 Unauthorized" + the WWW-Authenticate: header) and the client does not send the body. Being answered with a 401 status code and the corresponding WWW-Authenticate: information, the client can now perform the request again and provides its credentials.