Michał Sikora

> If I read you correctly, you're suggesting we treat the HTTP entities as immutable. If so, I'm totally in for this. Yes, this would be one thing to do...

To be honest, to make it simple, I would just divide and conquer and for now just split into three separate entities - `Transaction`, `Request`, `Response` with the same data...

@vbuberen Can I assign myself to it? If you don't work on it, I think I could start working on it this or next month. I'd provide here my general...

My plan for approaching it is as follows. Introduce new persistence models. These models would be pure data classes, and I want to remove all logic like URL formatting, things...

> Looks good to me. The only thing that comes to my mind is: > > > ` val redactedHeaders: Headers,` > > ` val body: HttpBody?,` > > I...

The confusing issue of missing headers comes up so often that I think we should make documentation more visible. https://github.com/ChuckerTeam/chucker#faq- #331 #433 #474 #531 #608 > Additionally, if I go...

It would be a hard task. Chucker uses interceptor API to inspect HTTP requests. Web sockets do not use this mechanism and the only thing you could do is to...

One consideration might be to create also an extensions like this in the external library. ```kotlin fun Interceptor.stripping(headerName: String): Interceptor ``` It would make it easier for Kotlin users to...

Yes, I like this idea. Didn't think of using `CallFactory`. Maybe I would just make it immutable, and configure all filters in the constructor with a default parameter (or use...

Could you make a PR for this? > why recommend/guide users towards using an application interceptor? I don't think it is a recommendation. Just the way things were documented. I...