Closed Bug 1069587 Opened 11 years ago Closed 11 years ago

logs show 14% of all responses are http status 401

Categories

(Hello (Loop) :: Server, defect)

Product:
Hello (Loop)
Component:
Server
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: edwong, Unassigned)

Details

(Whiteboard: [qa+])

Look here: https://kibana.shared.us-west-2.prod.mozaws.net/index.html#/dashboard/file/loop_http_status.json as of 9/4 ( about the time loop was uplifted to Aurora/Beta) we see a lot of 401 http responses to POST /registration HTTP/1.1 It looks like they're all from six specific IPs.
note that I don't have access to this dashboard (user 'ametaireau@mozilla.com' is not authorized). I'm not sure why we are getting these, I don't think there were any change in how the clients are authenticating. I'm NI Standard8 here for more feedback.
Flags: needinfo?(standard8)
Adding a few more people who might be interested...
Whiteboard: [qa+]
(In reply to Alexis Metaireau (:alexis) from comment #1) > note that I don't have access to this dashboard (user > 'ametaireau@mozilla.com' is not authorized). > You should have access using alexis@mozilla.com. I can add your official ldap if that works better for you.
Ah, thx. That's okay, I though I should be using the ldap id.
The "Hosts: Errors" on this dashboard counts the number of errors a specific loop server has seen. These change whenever we do loop deploys. I'm guessing the disproportionate number of errors is because the newer servers haven't been around that long. Another thing to mention is that the loop client server (call.m.c) and loop app server (loop.s.m.c) currently both report to this dashboard and look the same except for the request paths. That's why if you look at the current day you'll see two levels of errors between the four hosts (two client, two app).
(In reply to Wesley Dawson [:whd] from comment #5) > The "Hosts: Errors" on this dashboard counts the number of errors a specific > loop server has seen. These change whenever we do loop deploys. I'm guessing > the disproportionate number of errors is because the newer servers haven't > been around that long. The servers are still using the same data though, aren't they? I can't think of any recent registration changes - I think the only significant ones we had were six weeks before - just before 33 went to aurora. Also, I'm not allowed into the dashboard, is there any more detailed information on the 401s, I think I've seen there's a sub-field reported to the client.
Flags: needinfo?(standard8)
Yes, the server is using the same data. I don't see anything specific in the dashboard that could help us more.
As for 0.12.2 we have landed something that will help us to investigate this errors.
0.12.2 is in Stage. Should go to Production Monday 9/22...
Status: NEW → ASSIGNED
We have this deployed to a production stack that's not externally visible. We can swap the dns over later once everyone is around.
After some checking, it seems that the errors we see are only due to hawk requests not being correct, nothing else. Since nothing changed on the clients, I think we should consider these normal. In case we see a different number of error in the future (e.g. if that increases) we should pay extra attention, but for now I would consider these normal.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
> only due to hawk requests not being correct Sorry, this isn't clear: they are actually missing the authentication header, and thus aren't considered valid by the server. The normal behaviour in this case is to reject the request with a 401, and that's what happens here.
ok.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.