[Response] No Response Body Captured about home HOT 11 CLOSED

Looking at this a bit more closely--it's by design. Express defaults to using using ETag's, which allow the server to determine whether the browser already has (cached) the content about-to-be returned by the server. If so, then the server alters the response to a 304 and omits the body, and the browser will simply use the body from its cache.

In my testing, in all cases where Glimpse captures a request returning 200 it also correctly captures the response body. In all cases where Glimpse captures a request returning 304, the response body is empty (as expected).

from home.

For this, is there something in the UI that we can show that more clearly indicates this was a 304 hence no body? Chet's expectation here is not unreasonable.

from home.

/cc @avanderhoorn @nikmd23 - would be curious to know what your experience was with glimpse v1.

Feel free to remove the beta/early beta tags if we feel this is too big.

from home.

@chetsangnil had created #8 related to indicating when no value--in particular, no body--exists. I imagine that this could piggypack on that. E.g. a (!) icon next to a standard No body text that, when clicked, shows a text bubble that indicates that a 304 response isn't expected to have a body.

from home.

I think there may be two issues here.

The first, as @chetsangnil articulated, I think should be solved by #8.

However, when I look at the message being generated, I'm surprised to see the status code is 200. In ETag situations, a 304 should be returned (which means "hey client, use the content you have in your cache, I'm not going to re-send it"). A 200 would indicate "hey client, what you have is stale, use this instead".

So it looks like we're showing a 200 when we should be showing a 304?

@chetsangnil, can you confirm by comparing what Glimpse is showing to what your browsers dev tools show? I can walk you through how to do that.

from home.

Totally my bad; must have been a long day. I kept reading @chetsangnil's response ETag (which happened to start with 304) as the status code (listed directly below it). Copying his handler into my own sample app, I too see 200 responses with no body content captured by Glimpse (despite Chrome DevTools saying/showing a body was delivered).

I don't see this in the sample Sticker app, however.

from home.

In HttpProxy.ts it seems like we're calling the HTTP server handling logic before attaching/patching the request/response events/functions, which may introduce a race condition that could miss response data events. This seems to work for the Sticker sample app, but not for this simpler app. Maybe our sample tends to have large enough bodies to win the race?

If I move the invocation of the callback to after the subscription/patching, then Glimpse captures the body as expected. It looks like that code has been unchanged since @nebrius added body capturing, so he may have the best idea as to the intent of that ordering.

from home.

Ping @nebrius ;)

from home.

thanks @nikmd23. I noticed that this repo doesn't drop notifications in slack, can you update that?

from home.

Ok, looking at the code, I see what you're talking about. There's no specific reason it's ordered the way it is other than historical reasons, so it's fine to bump it to the bottom AFAIK. We should of course test for regressions.

from home.

Sorry it took me two weeks @nebrius, but this repo is now configured in Slack

from home.