Closed thijskh closed 10 months ago
Well, the function could be extended to look at the request headers (instead of the response headers, only), if the response is a 304. In that case it could check if the request headers contained preconditions and then hide the request.
It's a bit difficult to reproduce this. Could you supply an exported trace with a 304? I think I can fiddle around with that then ;-)
SAML-tracer-export-2023-10-10T07 26 31.558Z.json.txt
I see it on HTTP/200 resources as well. Trace attached, but note I had to rename it to .txt to be able to upload it here. Could it perhaps be related to HTTP/2.0 ?
Update: Strange detail though: I now can't reproduce this myself.. When I try and make the same trace again, the same file is being filtered (no cache, exact same response)
Unfortunately the request you highlighted isn't contained in the exported file at all. Or am I missing something? 👀
You are right, I'll upload a new trace tomorrow.. The trace was made after the screenshot and I suspect browser cache from not requesting the resource on the second run
I'm sorry, I can no longer reproduce this. The issue still exists for the .woff2 files though (content-type: font/woff2)
The woff issue I might have fixed in 83bc59cb7e345d7a14aafc59af047959966c821a, without noticing you proposed a similar fix for that at the same time. But right after decided on a more structural approach in #92.
I don't see 304 resources anymore when filtering is on.
What I do still see are grey resources in the list. These are all requests that are raced, accourding to devtools. The SAML tracer does not have a response for them, just the request. Therefore I think we cannot really know they are resources at all, since we don't have a mime type.
The woff issue I might have fixed in 83bc59c, without noticing you proposed a similar fix for that at the same time. But right after decided on a more structural approach in #92.
Yes, yours is much butter!
So all in all, maybe just close this?
Agreed!
When filter resources is enabled, I still see (gray) lines for some png, css and js. I strongly suspect these are resources that return an 304 Not Modified HTTP response.
Looking at the code I think it's this part that makes them not filtered: no content-type is sent in this case, so true is returned: https://github.com/UNINETT/SAML-tracer/blob/bfa10c1d50ba98bcd40aeab66efd6dfc62d36935/src/SAMLTrace.js#L435-L439
Not sure what a good solution is: special case 304 and also don't display any 304 reponses when filter resources is enabled?