EVE Technology Lab

I have been using the authenticated CREST API for over a month now to set waypoints for my characters. Usually this works entirely fine, but some evenings the only navigation API responses that crest returns are "502 Bad Gateway" errors.

HTTP/1.1 502 Bad Gateway
Server: nginx/1.2.0
Date: Wed, 09 Mar 2016 19:24:22 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Cache-Status: BYPASS

Gateway error communicating with EVE proxy

I ran into this issue a handful of times now and every time it appears that the problem itself just disappears the next day or the day after without any modifications to my own application. I can connect just fine to https://crest-tq.eveonline.com, and (deliberately) passing an incorrect authorization bearer will yield the expected "Invalid authorization" error. Only when the bearer is correct and the request is passed to the navigation API it will return above responses (Tested this both in my own code and in SoapUI).

Public crest on the other hand works like a charm when this issue pops up. I suspect this is just an infrequent issue with crest itself by now but i am wondering if anyone else is running into this when using the navigation endpoint?

Welcome to the world of CREST:

https://forums.eveonline.com/default.aspx?g=posts&m=6388293#post6388293
https://forums.eveonline.com/default.aspx?g=posts&m=6155371#post6155371
https://forums.eveonline.com/default.aspx?g=posts&m=6145624#post6145624
https://forums.eveonline.com/default.aspx?g=posts&m=6396832#post6396832

Are there any actions one can take to increase chance of not getting a 502 on Market Import functionality of CREST?

Retry with a few seconds pause until you get a proper answer. This is literally the approach I take on zKillboard. In a 5 minute time span I can have anywhere from 200-1000 CREST requests with about a 0.1% error rate.

https://github.com/zKillboard/zKillboard/blob/master/classes/CrestTools.php#L18-L39

Hi Squizz , Thanks for the hint.

Unfortunately it does not help in my case, gave it a lot of tries in the last days.

The authed CREST behaviour seems pretty reproducable.

1. Login against EVE-outh2 is reliable, works fine in all cases.
2. If using then my application without running Eve client, no problems, never got the 502/bad Gateway message
3. If logging in to Eve client I have a 50% chance of getting 502/bad Gateway messages afterwards
4. First login to Eve client then to my application I have a chance of >75% of getting 502/bad Gateway
5. Keep logged in with my application but logoff / logon the Eve client often fix the issue with a high likeliness

I'm open to any suggestion, have not the faintest clue on how to fix that.

Can you confirm that Rtg's behaviour above is expected or a bug that's fixed in the Citadel release you mentioned? I'm seeing identical behaviour; if the EVE client is open and logged in then that user cannot authenticate via CREST in my web application (or using the IGB, ironically).

Do you have any suggestion as to how to troubleshoot this? There's two people in this thread and two more in the other one that are having this issue.

I get a 502 bad gateway returned if the EVE client is open and so do all of my users.

EDIT: To give more info on this... sorry, didn't get muchh sleep. :P

• Authorization code is successfully obtained (user gets redirected, accepts, redirects back)
• Access token is successfully obtained
• API endpoints are walked and the decode endpoint located (https://crest-tq.eveonline.com/decode/)
• GET request to the decode endpoint is made with an "Authorization: Bearer $" header
• An error 502 bad gateway is thrown

Going back through logs I've also gotten this on a POST to https://login.eveonline.com/oauth/token with Authorization: Basic and Host: login.eveonline.com set, although that one returns a 504.

Double edit: I can confirm that Pyfa has the same issue. If you're currently in-game doing the export fitting results in a 502 bad gateway.

HOLY ******* ****! JHAGSDUYASTD&*AS*D^ASD&*ASDGASD

Carbon Alabel was able to give me a reproducible test case and I finally have a working theory on why this is happening and why it happens on TQ but not Sisi or local test servers and why it was so hard to track down. I need to wait for the network admins to get into the office, turns out sane people are not awake at 0345 to answer questions about work.

IF this theory proves good I have an idea on how to fix it. The code fix wont ship until Tuesday next week at the earliest since that is the next deployment time for non-critical things but I may be able to convince people to make a change to our network configs today if this theory proves out.

Holy ******* ****... FAH P*HF*YHAUIDS!!!!!!!!!

p.s. always match your test environments to production

I hereby declare 502's caused by being logged in as fixed. Please correct me if I am wrong.

No thank you. Thank you for reporting it, giving details, being persistent, all of it. Some of these things are incredibly hard to track down and it helps to have threads like this.