charset=UTF-8 is not showing

[ilizma]

:writing_hand: Describe the bug

On the REQUEST tab, charset=UTF-8 is not showing on the header zone

:bomb: Steps to reproduce

1. Make an API call with okHttp that adds the header charset=UTF-8 automatically
2. go to Chucker and click the tab REQUEST
3. See the header zone
4. charset=UTF-8 is not showing

:wrench: Expected behavior

charset=UTF-8 is showing on the header zone

[cortinico]

Thanks for reporting @ilizma I was able to reproduce locally. We actually just show the headers that OkHTTP passes us. Specifically we should append the Request content-type to the View in the Request tab.

Here a screenshot from Charles for the /post request:

[MiSikora]

The problem is that these headers are added as a part of OkHttp after application interceptors and before network interceptors do their work. The only thing that Chucker could do here if used as an application interceptor is to not process the request that is in the chain but rather one that is being returned by the interceptor.

Basically it would have to do something like this.

override fun intercept(chain: Chain): Response {
  // Some code…

  try {
    val response = chain.proceed(chain.request())
    val responseForRequest = response.networkResponse() ?: response
    val requestToProcess = response.request()
    // Process the request
  } catch (e: IOException) {
    // Do whatever
  }

  // Some code…
}

But I don't think it is a good feature. Now, in case of an application interceptor, it mixes an application response with a network request. So it should always process a network response instead of an application response for the consistency. But at this point Chucker loses the flexibility of being used as an application interceptor. Another drawback is that requests are processed later or might not be processed at all in case of response failures.

I believe it should be up to the consumer. If they are interested in network traffic then use Chucker as a network interceptor.

[cortinico]

I believe it should be up to the consumer. If they are interested in network traffic then use Chucker as a network interceptor.

Agree on this point. I would avoid to do extra processing for exposing headers that are added by the library.

My suggestion was more related to:

Specifically we should append the Request content-type to the View in the Request tab.

We actually store the request content-type in the DB but we never show it to the user.

[ArjanSM]

Is this still up for grabs? Do we want to display the content-type in the Overview tab or the Request tab?

[cortinico]

Is this still up for grabs? Do we want to display the content-type in the Overview tab or the Request tab?

Yup this is up for grab 👍

[vbuberen]

I don't think there is anything to grab. We already discussed in issues like https://github.com/ChuckerTeam/chucker/issues/474 that Content-type appears or not depending in type of interceptor that user adds.

[cortinico]

I don't think there is anything to grab. We already discussed in issues like #474 that Content-type appears or not depending in type of interceptor that user adds.

Yup I misread my actual 2 year old response 🤦 We store content-type in the DB but it's pointless to manipulate the visualized header, and is up to the user to decide which interceptor to use. I'm closing as there are no actionables