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

[Discuss] Improve long URL handling in Kibana #111303

Closed
vadimkibana opened this issue Sep 6, 2021 · 6 comments
Closed

[Discuss] Improve long URL handling in Kibana #111303

vadimkibana opened this issue Sep 6, 2021 · 6 comments
Labels
impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@vadimkibana
Copy link
Contributor

To improve how long URLs are treated in Kibana, please consider below points for discussion:

  1. Come up with a way to measure the actual maximum URL length for a specific browser session.
  2. Do not enforce arbitrary limits on maximum length of URLs in Kibana.
  3. Allow developers to use the maximum length of URLs provided by each browser.
  4. For any warnings or errors use the actual detected maximum URL length supported by that specific browser the user is using instead of hard-coding some URL length values.
  5. Remove the state:storeInSessionStorage UI Setting. Instead, for each user session (each browser) detect the actual maximum URL length supported by that browser. state:storeInSessionStorage is applied to all users and all their devices, but each browser (even for the same user) may have different maximum URL length limits.
@vadimkibana vadimkibana added Team:AppServices Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc labels Sep 6, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-services (Team:AppServices)

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@rudolf
Copy link
Contributor

rudolf commented Sep 7, 2021

state:storeInSessionStorage is applied to all users and all their device

From the description it sounds like this was an experiment:

The URL can sometimes grow to be too large for some browsers to handle. To counter-act this we are testing if storing parts of the URL in session storage could help. Please let us know how it goes!

But it's not clear to me why we thought this wouldn't work for users or why there needed to be a way to opt-out. Also it seems to have been around since at least 2018.

Related: #67454

@pgayvallet
Copy link
Contributor

This was moved from legacy to core during the platform migration without any functional changes.

I agree that an arbitrary limit doesn't really make any sense.

Ihmo, we should/could either

  • detect the current browser's max length (not sure exactly how) and use it
  • use the max length of the most restrictive browser from our supported browsers list
  • drop this URL_MAX_LENGTH error altogether and just display a warning depending on the URL_WARNING_LENGTH

Some pointers:

if (errorType === 'urlOverflow') {
return (
<ErrorPage
title={i18n.translate('core.ui.errorUrlOverflow.errorTitle', {
defaultMessage: "The URL for this object is too long, and we can't display it",
})}
>
<UrlOverflowUi basePath={basePath} />
</ErrorPage>
);
}

if (absUrlLength > URL_MAX_LENGTH) {
const href = history.createHref({
pathname: ERROR_ROUTE,
search: `errorType=urlOverflow`,
});

this.stopHistoryListening = setupUrlOverflowDetection({
basePath: http.basePath,
history: application.history,
toasts: notifications.toasts,
uiSettings,
});

export const URL_MAX_LENGTH = IS_IE ? 2000 : 25000;
export const URL_WARNING_LENGTH = IS_IE ? 1000 : 24000;

@vadimkibana
Copy link
Contributor Author

Dropping the error and leaving the warning for now could be a good first step.

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Sep 10, 2021
@ppisljar
Copy link
Member

ppisljar commented Aug 8, 2022

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

@ppisljar ppisljar closed this as completed Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

5 participants