Closed aautio closed 7 years ago
The docs are correct... at the moment, if we don't have a Content-Type
it wont show up in the request history list. This is only a temporary limitation, we plan to add filtering to the history list which will give you full control over what you see.
That said, I'm interested in the use case for why you have no Content-Type
. Is it just because the request is so simple that you don't need it or is there another use case at play? Note, i know you technically don't need one but interested about your case.
I have some registration forms up and running where there is no need for any other feedback from the server than HTTP 200 OK. Thus there was no content-type in the responses.
But there actually is one another use case which might be problematic for Glimpse: dynamically generated images or "email tracking pixels" and so on. I'd guess that requests to an endpoint providing images will also be hidden? If that is the case it prevents me from inspecting these kinds of services as well.
So currently there is no way for me to override the default filter?
So currently there is no way for me to override the default filter?
Not at this exact moment. Out of curiosity... again trying to understand the use case, is there anything stopping you from returning a content type? Or do you feel that changes the semantics?
In my use case I can add the content-type 'json' to the responses without content-type.Thus get the request will be visible in Glimpse HUD.
Another way for me to get the requests to be visible in the HUD seems to be by adding Accept: application/json
header to the request. I think this is an undocumented feature? It might be a good workaround if someone else has a similar problem but can't edit the response for some reason.
I also have another set of APIs built on top of http://sharp.dimens.io/en/stable/ where I am doing all sorts of image manipulations. It would be great to inspect the requests to these image APIs as well. In these APIs the content-type is correctly set as the image.
Should we close this issue as it already is something you have already been planning for? I really like what Glimpse is providing so far and the direction you are taking it and I'll keep an eye on the project anyway :)
Ya filtering is definitely coming. We are trying to get it in the next release but if not then the one after.
When you say that you would like to see the calls to the APIs built on top of sharp
, are these web APIs? If we already support that use case... assuming node is running there to. Basically you will install just the @glimpse/glimpse-agent-node
and configure it to point to the glimpse "server" running in your original process. By doing this, you will not only see the details of your origin requests like you do at the moment (along with the where the client http requests are made in that "origin" request), but all the server side of that http request.
The following describes the architecture in play http://node.getglimpse.com/docs/user-guide/glimpse-architecture/ and this is a sample which shows the actual code setup https://github.com/Glimpse/Glimpse.Node.Samples/tree/master/calculator-micro-services. Let me know if you have any questions in setting it up or how you find it once its running.
Sorry, english is not my natural language, so I might make things sound more complex than they are. Here is a demo about what is a problem for me: https://filteringdemo-softzvdluw.now.sh/
You can see full sources of that demo at https://filteringdemo-softzvdluw.now.sh/_src
There is an image generated on-the-fly with sharp
if you'll access https://filteringdemo-softzvdluw.now.sh/image ... But you will not see any of those requests in the Glimpse Client HUD, because Glimpse ignores responses with content type image/jpeg
. The Glimpse Client HUD is available at https://filteringdemo-softzvdluw.now.sh/glimpse/client
I think this will be resolved as well when Glimpse gets the features to provide full control over which requests are shown. I'll now stop spamming here so I won't interfere with your progress :) Thanks for helping and clarifying things!
Not a worries and thanks for providing this! Filtering will definitely help with this case... will keep you updated as we make progress on that.
@davidkpiano can you confirm that this use case will be fixed with the work you have done?
Yes, in the next release, you will be able to see requests with no content-type
by selecting the Other filter (not selected by default) 🎉
Also, your filter preferences will be persisted even if you close your browser, so you can have a consistent filter preference for all your debugging sessions (until you reset the filters).
Fix for this is availabe on NPM now with glimpse version 0.21.5.
Excellent, thanks!
The troubleshooting documentation at http://node.getglimpse.com/docs/support/troubleshooting/#i-don-t-see-my-request-in-the-glimpse-client-request-history states that
To reduce noise, the Glimpse client has a static filter that excludes certain requests from that list: Requests for content other than documents (e.g. HTML or text) and data (e.g. JSON or XML)
It seems that if a response does not have
Content-Type
header and if it has an empty body, then the corresponding request does not show up in the Glimpse client. Thus services which simply return an HTTP 200 OK without any further data do not show up.Is there a way to configure the mentioned static filter to not hide these kinds of responses? Can I override the filter somehow?
The current approach does not work with simple services such as this one here below: