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

Can't create really long funnels due to GET limitation #4554

Closed
2 tasks
timgl opened this issue Jun 1, 2021 · 1 comment · Fixed by #4602, #4670 or #4768
Closed
2 tasks

Can't create really long funnels due to GET limitation #4554

timgl opened this issue Jun 1, 2021 · 1 comment · Fixed by #4602, #4670 or #4768
Assignees
Labels
bug Something isn't working right good first issue Good for newcomers

Comments

@timgl
Copy link
Collaborator

timgl commented Jun 1, 2021

Bug description

We've had a user create a funnel with Korean characters and 17 steps, which causes this issue:
image

Expected behavior

We should send requests to api/insight/funnel using POST instead of GET.

How to reproduce

Environment

  • PostHog Cloud
  • self-hosted PostHog, version/commit: please provide

Additional context

Thank you for your bug report – we love squashing them!

@timgl timgl added bug Something isn't working right good first issue Good for newcomers core-experience labels Jun 1, 2021
@alexkim205
Copy link
Contributor

alexkim205 commented Jun 1, 2021

How to Reproduce

  1. Create a filter with a loooot of steps. See this one.
  2. Check network request
  3. Verify we get same long request error -> Request Line is too large (4216 > 4094)

Note: This bug only occurs in Self-Hosted and Cloud setups
This limitation doesn't exist in local dev setup because there is no gunicorn layer in local dev that limits the number of chars in our requests docs. It's probably why we didn't notice the bug. An example pipeline on localhost whose request is ~6000 chars long works correctly.

Solution A - Tim's solution

Change GET to POST endpoint.

Pros

  • No restriction on limit
  • Secure

Cons

  • Involves deep code change (frontend and backend stack)
  • Confusing API (acts like a GET, looks like a POST)

Solution B - Change gunicorn limit_request_line config <-- Chose this one b/c pro's are stronger and con's can be mitigated

Change limit_request_line to 0 (unlimited) or 8190 (max).

Pros

  • Doesn't involve deep code change
  • API method stays consistent with action

Cons

  • Unlimited request length is a security risk for DDOS attacks. Can mitigate by setting to 8190.

Next Steps

  1. Write test. Run tests in self hosted env which will fail.
  2. Make fix (choose A or B above).
  3. Testing
  4. PR and merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working right good first issue Good for newcomers
Projects
None yet
2 participants