Page MenuHomePhabricator

[DeepCat] Switch from GET to POST requests
Closed, DeclinedPublic21 Estimated Story Points


Investigation has happened and here's the conclusion after @gabriel-wmde @WMDE-Fisch looked into this:


There are many changes needed that may be out of scope for a simple gadget. To illustrate, here is a description of the changes that would have to be done to the Gadget code when using POST instead of GET:

  • Add code for changing the methods of the search forms.
  • Find a mechanism for persisting the deepcat search parameters. See below for suggestions.
  • Add code to convert search-related links to hidden form submissions. Without hidden form submission the links will run into the get limit again.

Persisting deepcat search parameters

To replace the generated "incategory" terms on the result page, the original search terms containing "deepcat:" terms must be persisted between the search page and the result page. Same for the errors from the AJAX calls. We have at least 2 options for persistence:

  1. Cookies/LocalStorage: If choosing this option, the Javascript must check if cookies/LocalStorage are enabled and display a message to the user if not. Can be done in the existing hint code. LocalStorage would be better than cookies for this since the server does not need the cookie, the cookie also has size limits and would bloat the HTTP requests.
  2. Mixing GET and POST*: The Gadget code in substituteSearchRequest and addErrorMsgField would have to be rewritten to append GET parameters (deepCatSearch and deepCatError) to the search forms actions instead of appending fields. The WebRequest class in the Wiki code munges GET and POST together (POST overriding GET), so mixing data sources is not a problem.

Convert search-related links

The search-related links are the scope links at the top of the search results and the paging links at the bottom of the search results. They contain the full search term string which will be truncated when the link is clicked. My proposal to solve this:

Rewrite appendToSearchLinks and instead of just appending the deepCatSearch parameter to the href, create an onClick handler for the links that does the following steps:

  1. Create a hidden form element with a POST action
  2. Set the action of the form to the href of the link (minus the search param)
  3. Append the deepCatSearch parameter to the action.
  4. Add search field to the form. The value could come from the link, but to be sure it could also be set when newSearchTerms is generated.
  5. Cancel the click event and submit the hidden form instead.

We discussed in the meeting on 2015-08-05 that we should not start with this before we've tackled T108023.

Event Timeline

Tobi_WMDE_SW raised the priority of this task from to Medium.
Tobi_WMDE_SW updated the task description. (Show Details)
Tobi_WMDE_SW set Security to None.
Tobi_WMDE_SW edited a custom field.

Just in case it wasn't evaluated already, there are other ways to do category intersection. The main search interface can't be expected to work with this. While there is no alternative in production, there are various tools for it in Tool Labs that may be suitable for use in a gadget.

  • FastCCI
  • CatGraph

Resources behind this gadget could work with maintainers of one or both of those tools to mature the service into something production-grade. Possibly exposed through MW API or RESTBase.

@Krinkle CatGraph is exactly what the DeepCat-Gadget is using and T89823 was the prerequisite in Cirrus.