A space to discuss GraphQL queries, mutations, troubleshooting, throttling, and best practices.
Starting today I am seeing about 15% of my GET order calls via the rest API return with an Error 414: Request URI Too Large
The API call I am using is to the following url, it isn't happening on all requests, but probably about 15% of the time. Not even reliably for the same order id.
I am using the API via ruby and my usage results in the following request
curl -X GET "https://your-development-store.myshopify.com/admin/api/2021-10/orders/{ORDER_ID}.json?fields=id%2Cemail%2Ccustomer%2Cfinancial_status%2Cline_items%2Cprocessed_at%2Cname%2Cphone%2Cadmin_graphql_api_id%2Cupdated_at" \
-H "X-Shopify-Access-Token: {access_token}"
curl -X GET "https://your-development-store.myshopify.com/admin/api/2021-07/orders/{ORDER_ID}.json?fields=id%2Cemail%2Ccustomer%2Cfinancial_status%2Cline_items%2Cprocessed_at%2Cname%2Cphone%2Cadmin_graphql_api_id%2Cupdated_at" \
-H "X-Shopify-Access-Token: {access_token}"
Could you please provide x-request-ids for the calls which failed? Do the calls fail if you omit the fields parameter?
To learn more visit the Shopify Help Center or the Community Blog.
The calls work fine when omitting the fields parameter.
I don't have the call ID's as this would only happen periodically and I could not get it to reliably reproduce when making the call and investigating the request-id. I could even make calls for the same order id and get a success, however removing the fields parameter stopped this from happening at all.
Ideally I can keep the fields parameter because it is more efficient to only request what is needed, but had to remove it due to this error.
This is on you! Error 414 is returned when a server realizes your request is too many characters. The absolutely simplest way to advance your code and walk away from this nasty is to switch to using GraphQL. With that, you can cherry-pick your fields for just the data you need, and never run into that clunky RestAPI limitation.
It is not realistic to expect infinite length URI, so they must be limited at some point. And you seem to have hit that limit, with the inclusion of fields. Odd though, as your sample requests are actually pretty tiny, and should not be victims of 414 from Shopify, all things considered. Tough bug to work around there!
@HunkyBill That's kind of what I had figured at this point. Was just strange that it started at a very sudden moment with no change on our end. Would have expected this when changing API version or adding fields but not at 1am on a random Monday morning with no change from our end.
Shopify has been processing orders since 2006. It is almost expected that at some point, you would expect drama! A couple of days here and there with sporadic 414 errors sprinkled across a few thousand clients. Just saying, if we are all grains of space dust, and the occasional neutrino invades the data center at the right moment, it's all toast.
Under Apache, the limit is a configurable value, LimitRequestLine. Change this value to something larger than its default of 8190 if you want to support a longer request URI. Extremely long URLs are usually a mistake. If you keep URLs under 2000 characters , they'll work in virtually any combination of client and server software. URI actually have a character limit depending on several things. Chrome limits url length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication. On most platforms, Chrome's omnibox limits URL display to 32kB (kMaxURLDisplayChars ) although a 1kB limit is used on VR platforms. IE - 2083 characters, Firefox - 2047 characters, Safari 80000 characters and Opera 190,000 characters.
To resolve the problem :
If exceed the request max length then the request truncated outside the limit by web server or browser without any warning. Some server truncated request data but the some server reject it because of data lose and they will return with response code 414.