Skip to content
This repository has been archived by the owner on Jun 16, 2018. It is now read-only.

Search or highlight by body contents. #10

Open
mhils opened this issue Apr 24, 2016 · 4 comments
Open

Search or highlight by body contents. #10

mhils opened this issue Apr 24, 2016 · 4 comments

Comments

@mhils
Copy link
Member

mhils commented Apr 24, 2016

Filters for request/response body are currently not implemented. This is a tricky feature, as we do not have the bodies in memory on the client side and we kind of need to query the server for this.

@mhils mhils changed the title Cannot search or highlight by body contents. Search or highlight by body contents. Apr 24, 2016
@cle1000
Copy link

cle1000 commented Aug 3, 2016

there are several ways to solve this problem:

  1. send the content with the flow to the client, so we can search the content on the client side
  2. send the filter to the server with a request and get the a list with matched flows back, do that on every flowupdate, flowadd,... event
  3. send the filter to the server with a request and get the a list with matched flows back, the server should also store the filters from the client and adds to each flow a field on which filters that flow matches
  4. send the filter to the server, the server adds an information to all flows -> flows will be automatically updated and so we have the needed information.

what do you think? do you have more ideas ?

@mhils
Copy link
Member Author

mhils commented Aug 4, 2016

Thanks for the write-up @cle1000.
@cortesi: Content search is maybe one of the most tricky parts we have - what are you thoughts on this? This is also a feature that does not really translate to our static viewer, so I'd be interested to hear your thoughts.

My five cents: 1 is a possible resource hog - not what we want. 3 and 4 are nice solutions, but this implies keeping state on the server and interleaving filter/highlight logic with the whole flow list components. I'm a bit a fraid that this ends up as spaghetti. 2 is not really pretty, but leaves all flow content searching in an isolated place/API. The main issue here would be that once we receive a flow update, we need to do an asynchronous request to the server, leaving a small time period in between where we don't know how to handle the flow. for positive/"show only" filters that probably wouldn't be too bad, as they just stay hidden for a bit longer. For negative filters, we'd have flows show up incorrectly and then quickly disappear again - that sucks, but might be enough of an edge case that we don't need to care about it.

@cle1000
Copy link

cle1000 commented Aug 7, 2016

@cortesi: what do you think? i should implement this in the next two weeks as my "last" gsoc feature :)

@arya6000
Copy link

any update on this feature?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants