Dealing with REST HTTP GET Exceeds the Max Length

Recently while I was putting together a HTTP REST call to get some information from SharePoint 2016 (on-premise) document library I ran into some problems with the length of the call. Specifically I got the dreaded:

The length of the URL for this request exceeds the configures maxUrlLength value.

That’s the basic problem with HTTP GET, the requests are limited length. This length restriction depends on a combination of factors, but it basically boils down to what the Web server has been set to accept. With SharePoint on-premise it is the maxUrlLength set in the web.config file, and with other software maximum HTTP GET length is similarly set at the server level.

Most advice says to update the maximum maxUrlLength value for GET requests in the SharePoint web.config file to be larger than it currently is. That’s nice if you are the main SharePoint server admin and have access on the server, but not so great if you are just trying to write a REST query with a path that’s a bit long.

Other advice says to change your request to HTTP POST. To change your query to HTTP POST rather than HTTP GET needs rewriting and doesn’t really make sense for something that should easily be handled in a HTTP GET request.

In my case the SharePoint Web server would not accept any requests that were longer than 285 characters long. This was a problem because the document library that I was querying with my REST query was full of nested long named sub-folders, and the documents also had long names. It was just a short matter of time until I ran across a folder path that was too long than the allowed 285 character limit.

Specifically, I was doing the HTTP GET REST call with the format:

https://mySharePointSite.com/sites/SubSiteName/DocLibraryName/_api/Web/GetFileByServerRelativeUrl(/sites/SubSiteName/DocLibraryName/Folder1/Folder2/Folder3/FileName.txt)/listItemAllFields/id

With this verbose syntax mixed with the long folder path there’s no wonder that I was quickly hitting the maximum HTTP GET URL length.

So what’s the solution? How can we get this query to work without major server changes?

The answer is to use a URL variable and parameter. The server puts HTTP Max GET request length limits on the base part of the URL itself, but does not apply this restriction to the parameters sent in the URL. Who would have guessed!

Long story short, we can update the URL example above to put the SharePoint document library file path into a passed parameter. Since the longest part of the HTTP request is the path to the document in the document library we can significantly reduce the GET request size by putting everything in the GetFileByServerRelativeUrl REST function into a URL parameter variable.

In the URL below see how I’ve added a parameter arbitrarily called @v into the function and then moved the document library path into the URL parameters section of the URL:

https://mySharePointSite.com/sites/SubSiteName/DocLibraryName/_api/Web/GetFileByServerRelativeUrl(@v)/listItemAllFields/id?@v= ‘ /sites/SubSiteName/DocLibraryName/Folder1/Folder2/Folder3/FileName.txt‘

One side effect I have found with changing your REST call to using a parameter variable is the way characters such as & are handled. If, for example, there is a & character somewhere in your path and now you move it into a parameter, it will cause an error. This is because the & needs to be URL-escaped when in parameter form (Note that it does not need to be escaped when it is part of the base URL).

So make sure that if you are using a parameter variable where the path may contain an & character, make sure to replace the & character with its URL escaped code: %26

To summarize:

• REST HTTP GET requests are good for quickly and easily getting information
• HTTP GET requests are limited in the number of characters passed. This is usually set at the server level.
• HTTP GET requests do not consider parameters passed in the URL as part of the request length maximum
• You can use URL variables with parameters to snip out long sections of the URL such as the path in a document library. This can let you move long text into the parameters section of the URL where they are not considered part of the GET Request Maximum length restrictions.
• Escape & characters in the parameter string with the URL code %26