Better grooming of created queryset content for search results is needed.

[rjsparks]

Right now, if you type "dkim" into the main page searchbox, you are redirected to a search result page that has this URL:

https://datatracker.ietf.org/doc/search?csrfmiddlewaretoken=<actual token elided>&name=dkim&sort=&rfcs=on&activedrafts=on&by=group&group=

This is silly. The issue is that the view is blindly copying things from the submitted form into the queryset.
It should, instead, only copy the things that make sense. The csrfmiddlewaretoken should never be copied. Any thing that would result in key= with no value should be elided.

[pselkirk]

The csrf_token tag should not be used in forms that don't use POST. (We can tell that this does GET because the form element has action="{% url 'ietf.doc.views_search.search' %}" and not method="post".) Apparently if you GET such a form, it adds a csrfmiddlewaretoken to the URL. Now we know.

Separately from that, the group parameter is empty because by is pre-selected as group, i.e. the radio button is pre-checked for "WG", but nothing is entered in the text field. If I remove the initial='group' argument from SearchForm.by, that empty field goes away (as well as by=group), but the user who wants to search by WG would first have to check the radio button, so that's a UI change.

The empty sort parameter is similar - we haven't chosen a sort (which we can only do from the search results page).

From what I've been able to find, a URL with empy parameters is pretty benign, and I haven't found a way to suppress it in the Form or Field classes. If there is a way, I'd love to be enlightened. @jennifer-richards

Separately from that as well, you say "The issue is that the view is blindly copying things from the submitted form into the queryset." But that all happens after the generated URL is received. For purposes of filtering the search results in retrieve_search_results, it may be slightly more efficient to skip filtering on empty criteria, but not so as I'd notice.

So I think we're good with removing the csrf_token tag, and letting the other stuff slide.

[jennifer-richards]

Don't know offhand of a way to suppress it, but that doesn't mean there isn't one. Is there a reason not to change this to a POST?

[pselkirk]

It's just a search form, it's not changing anything on the server. So I don't see why it shouldn't be GET?

[jennifer-richards]

It should be GET in those terms, but since GET can't have a body it forces the unwieldy URL. I'm not terribly bothered by the bending of the convention. It would mean that the search URL cannot be shared which is a potentially useful feature.

After poking around a bit, your observation that this "happens after the generated URL is received" is the rub here. The only solutions I know of that leave a shareable, minimal URL are using javascript to disable the unneeded fields or to POST the search to an endpoint that redirects to a GET with the non-empty params.

I think using JS or living with the poor aesthetics are the better options.

[rjsparks]

The search form, in its current state, is used by many other pages essentially as an internal api (almost all pages that list documents use it). A shift to POST will cause quite a bit more change than one would expect. We should make that change anyhow, but I don't think this particular issue is the tipping point that pushes us into that investment.

[richsalz]

I think a better approach would be to advocate for the "HTTP SEARCH" method, RFC 5323