Bettter Search

[shirshak55]

I think the search requires some improvement. It would be awesome if we could search on request for every detail like header, response code, etc.

Also, it would be nice if we could easily search in WebSocket responses, streaming responses, etc. Currently, I do something like body=*haystack.

[pimterry]

Hi @shirshak55! I think most of this is already supported, for example you can search with:

• header[content-type] to find requests with a content-type header
• header[my-header]*=test to find all requests with a my-header header containing 'test'
• status=404 to find all 404 requests

I think this already covers almost every detail. You can see the full list by selecting the empty search field and pressing 'up', or you can just start typing and look at the suggestions.

WebSocket messages are a good point though, that's the one thing that's not searchable yet (because it's stil very new). We could include this in the body search, or we could have a new filter websocketMessage*=test that searches websocket messages specifically. What do you think?

Other than WebSockets, are there any other specific filters that you think are missing?

[shirshak55]

@pimterry the problem is I don't know which header is used. I usually use a blind search like finding the request where 231234 is used. It could be in the body, headers, etc.

I wish there was a global search that searches on everything. So I don't have to do header[header_I_don't_know]*= 231234 , body*= 231234, websocketMessage *= 231234

Maybe searchAll *= 231234 something would be good that would search on everything.

I don't chrome devtool also has this feature. The only problem with current chrome dev tools is it doesn't search on WebSocket responses.

[pimterry]

Ah, I see, that makes good sense. You can just use freeform search (just type in anything, no filters) and it will search most data (e.g. all header names & values) but it doesn't search message bodies because that's relatively expensive (we have to decode every single request & response to do it, and we avoid doing that normally until you actually look at the request because it's slow).

How about contains(231234)? That could match against absolutely every part of the request. Most programming languages use contains to search strings, so I think the name would probably make sense, and we already use the bracket syntax like that for not() and or().

[shirshak55]

@pimterry I am okay with any syntax. contains is a great choice. Also, I generally don't care about perf in cases like that because I frequently clear the requests. Maybe we can add another method like contains_all (to indicate it will search everything including body.)

[pb36]

@pimterry this feature would be indeed very useful for searching the data instead of individually searching into headers or body.

[pimterry]

I'm absurdly busy in the short term, so I'm struggling to find time for this, but yes I'd be very happy to add it, I think it makes good sense.

In the meantime, pull requests are very welcome! The filters are defined here: https://github.com/httptoolkit/httptoolkit-ui/blob/master/src/model/filters/search-filters.ts. Do please comment here if you do start working on this. In case you're not aware, all contributors get totally free HTTP Toolkit Pro, more details on contribution here: https://github.com/httptoolkit/httptoolkit/#contributing-directly

[pimterry]

contains(something) is now supported! It matches against pretty much everything: request method, URL, request & response headers, request & response body, status code, status message, websocket messages, WebRTC messages, and WebRTC/TLS connection URLs.

I think this probably covers this issue, so I'm going to close this. One thing worth noting is that the performance on this is not great, since it has to search through a huge amount of data, especially if you have many responses with large bodies. Using a more specific filter is going to feel faster, if you know where in the request/response you're looking for your data.

If you run into issues with that, do please reply here or open a new issue, since I think there's probably improvements available there with more complex caching etc.

You can also probably mitigate any performance problems by filtering down your data with other filters before using this, e.g. hostname*=example.com contains(hello) will only check against example.com requests, not all requests, which may be much quicker.