3

Since a few weeks, I'm getting 400 - Bad Request errors now and then, on pretty standard API calls like fetching post details. This is the response I get:

<DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid URL</h2>
<hr><p>HTTP Error 400. The request URL is invalid.</p>
</BODY></HTML>

which leads me to believe something is wrong on the server side; normally, a 'real' bad request is met with a JSON response, like here.

I got that this morning for a GET call to

https://api.stackexchange.com/2.2/answers/3379083;3479797;3485080;3532536;3588593;3707741;3774262;3897582;3956977;4146496;4216746;4252051;4325734;4328661;4422405;4454080;4576180;4579476;4662930;4669874;4800981;4830891;4966813;4983149;5007784;5079482;5094418;5098217;5113940;5207041;5223793;5289474;5320683;5384201;5394784;5398512;5411333;5414050;5476133;5483811;5487894;5571620;5658863;5665004;5723151;5750579;5785013;5785435;5875843;5893447;5893600;5919049;6163052;6163411;6210459;6337955;6385814;6402358;6489721;6686494;6770732;6866354;6908297;6966675;7054963;7215895;7220022;7222761;7251593;7255421;7336998;7422381;7543102;7604800;7628070;7701256;7701271;7706953;7707553;7815148;7829578;7886173;7905506;7910771;7917144;7957760;8103815;8131752;8249070;8283530;8304194;8325611;8373652;8397476;8403988;8460209;8509208;8528185;8543589;8547485?sort=creation&order=asc&pageSize=100&site=stackoverflow&filter=!)Q2B_A1DAAeCErOKdxRVbW2a&key=L8n*CvRX3ZsedRQicxnjIA((

I'm trying it a few times in my browser now, and it sometimes works, sometimes it doesn't. What's going on here?

There doesn't seem to be a difference between v2.2 and v2.3.

Improve this question
11
  • I repro-ed this, as in: it works now and then ...
    – rene ♦
    Commented Jul 19, 2021 at 9:55
  • I'm also routinely getting errors on both the 2.2 and 2.3 API for at least days, if not weeks. The errors will commonly be CORS errors, which in the past the SE API has appeared to use as a secondary method of rate limiting (effectively, if not intentionally). If I disable CORS, then I get the "Bad Request" response. However, I used to really only get these when having a lot of requests in flight at the same time (i.e. on one script which was specifically written to be able to hit the questions endpoint fairly hard). At this point, I'm getting such errors on routine, single requests.
    – Makyen
    Commented Jul 19, 2021 at 13:41
  • @Makyen for cors I had another bug open: meta.stackexchange.com/questions/364500/…
    – rene ♦
    Commented Jul 19, 2021 at 13:42
  • It may be better to have this on MSE, rather than here. At least in the past, reports of issues have been much more likely to be addressed if they're on MSE, rather than here or MSO. However, my most notable experiences with that were prior to the advent of the status-review tag. I'm unsure if the existence of status-review will be sufficient to overcome the bias for looking on MSE for API/network-wide issues.
    – Makyen
    Commented Jul 19, 2021 at 13:51
  • @Makyen I already took care of that earlier. Stack Apps is monitored now for bugs and status review. Changed shortly after we got our diamonds here. See also: stackapps.com/a/8979
    – rene ♦
    Commented Jul 19, 2021 at 14:11
  • Probably related to Using a custom filter with a lot of tags throws an error on refreshing the page, as shorter URLs work just fine (for me at least).
    – double-beep
    Commented Jul 19, 2021 at 18:40
  • @double-beep While this might be easier to reproduce with larger requests, I thought I'd seen it even on some requests which had quite short URLs (e.g. with a single post ID).
    – Makyen
    Commented Jul 19, 2021 at 18:53
  • I'll be looking into this but my gut feeling is that the URL is just too long. Historically, the maximum URL length was 923 characters (or maybe bytes?) but I'm not sure what it's currently set at. In the iOS app, I did batching of requests like this to limit the URL length.
    – Brian Nickel
    Commented Jul 19, 2021 at 21:10
  • @BrianNickel Would that be causing an intermittent issue? In the cases I have this problem, I can repeat the exact request and have it work. Usually, if a URL is hitting a length limit, that's ahard failure, not an intermittent failure. I'd note that this is, at least for me, intermingled with the CORS issue, which others have also experienced. I'd note that, in the past, I've also gotten similar responses when I've been hitting the SE API fairly hard, and got these, even when obeying backoff. In those cases, it's appeared to be a secondary rate limiting scheme.
    – Makyen
    Commented Jul 19, 2021 at 22:03
  • @Makyen My theory would be that the request isn't pinned to a specific server and the different servers have different baseline configurations for max URL length. The error message is happening before we reach the application code and the message is just IIS's way of saying it can't interpret the URL. If it got past that, we'd end up with JSON.
    – Brian Nickel
    Commented Jul 20, 2021 at 18:38
  • @BrianNickel I'm seeing the problem for a week now too. From some experiments, I can reproduce the problem on /2.3/questions/ URLs (and others) with message list with 30 IDs totaling 268 chars (the list only). Example of such URL: pastebin.com/biHBsjsC – When I remove one message ID, the problem seems to stop happening. I've seen a similar issue right after 2.3 API release. But it was less frequent and I didn't investigate back then closer. And the problem disappeared after a while. Now it's back and much more frequent (5-10%). Before there was no problem with URLs 900 chars long.
    – Martin Prikryl
    Commented Jul 21, 2021 at 8:34

1 Answer 1

Reset to default
5

This is fixed.

I was able to pin down the issue two web servers. After SRE verified that the URL length settings were fine, I was able to narrow the issue to individual path components over the IIS default of 260 characters as described in https://stackoverflow.com/a/16903689/860000. SRE confirmed that UrlSegmentMaxLength was correct so there was only one thing left to do...

We turned the servers off and back on again.

Having looked at the new server defaults and what we're passing in, we should have no problem with a URL with 100 concatenated ids, at least from the HTTP layer URL parsing perspective.

Improve this answer
1
  • Thank you! rolls back automatic retry functionality in client
    – Glorfindel ♦
    Commented Jul 22, 2021 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .