Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request-URI Too Long #590

Closed
Glavin001 opened this issue Sep 7, 2017 · 10 comments
Closed

Request-URI Too Long #590

Glavin001 opened this issue Sep 7, 2017 · 10 comments

Comments

@Glavin001
Copy link

My team is using GraphiQL and loving it! Thank you for such an awesome tool.

Recently we have been receiving the following error on our longer queries:

Request-URI Too Long
 
The requested URL's length exceeds the capacity limit for this server.

I narrowed it down to Apache rejecting the URL:

image

However, our Infrastructure team will not increase the character count max for Apache stating:

There is a 2k character count max for most browsers, servers, etc. You have a URL with 12859 characters.

Is there anything we can do to reduce the URL character count? Thanks in advance!

@AGS-
Copy link
Member

AGS- commented Sep 15, 2017

I've noticed this has come up a bit. I'm not 100% sure if something can be done, but I'll take a look at it this weekend and see if I can figure something out. In the meantime if anyone has any suggestions that would be great.

@asiandrummer
Copy link
Contributor

@Glavin001 At Facebook we solve this problem by storing the query/variable (and maybe response depending on your use case) somewhere locally/on the server and give an ID to access it. Would this be a feasible solution?

@Glavin001
Copy link
Author

@asiandrummer would what you described be similar to GraphQL Bin's Share functionality: https://github.com/graphcool/graphql-playground#how-does-graphql-bin-work ?

I suppose it would work, however is this something builtin to GraphiQL or an external tool you built?

@michaelcurry
Copy link

@asiandrummer Can you please give an example of how this would be done. I am new to the community and would like to implement this. How would you go about storing the query on the server then allowing the client to specify what query it wants? Can you please point me to some documentation or a post that you know of explaining this approach in further detail?

@asiandrummer
Copy link
Contributor

@michaelcurry Hi there! Basically you would map an unique key to a query string (and probably also variables) and store the combination in the server. There isn't an official documentation as far as I know about this topic since it's one of the advanced topics, but I've found a helpful guide to get you started - https://dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5

The above link is closely tied with JavaScript/Apollo tools, but it'd be useful to give you a basic understanding of how a persisted query would be created. Let me know if you have other questions about it please.

@asiandrummer
Copy link
Contributor

@Glavin001 I think my above comment answered your question, so I'm going to close this issue for now. Feel free to reopen if you disagree please.

@Glavin001
Copy link
Author

Persisted Queries will work when coupled with an app, such that the queries are known. However, my team's use case may be slightly different.

For example, we may have 1 larger query (shared by our team) which tests all fields for a particular model given some variables. The app (e.g. web app with React) itself may support all of these fields, although they are distributed over separate persisted queries. Thus, there exists no persisted query which satisfies the needs of my teammates poking around with GraphiQL.

Of course, this example is contrived and may even be against best practices (?). We simply love how easy GraphQL makes it for writing a new query to fit our needs on a case by case basis, and how that can be leveraged for testing/debugging the API.

@asiandrummer
Copy link
Contributor

@Glavin001 If I understood correctly, an example would be that you just want to play with GraphiQL and share some queries across team members, but you don't necessarily want to create a persisted query, correct?

At FB we use persisted queries and another way to share queries around - usually loading by persisted query IDs are good enough, but for testing purposes sometimes we need to share queries that aren't necessarily persisted. We have a way to 1) copy the query/variables/response in an internal wiki-like webpage, 2) create an ID for that (let's call it a text document ID for instance), and 3) load and parse that web-based text document to load queries. I guess we could call it another way to "persist" a query, just not the ones that are being used in an app ;)

@Glavin001
Copy link
Author

You understand my situation correctly.

I will need time to investigate your proposed workaround. Thank you for your support!

@orospakr
Copy link

As a thought, perhaps it's useful to try stripping out unnecessary whitespace (if GraphiQL doesn't already). You might end up with quite a few %20s being sent in the URI if the query the user has typed into GraphiQL is nicely indented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants