I have a RequestLog feature completely decoupled from the application logic.
I capture the request/response in a pre request filter. To acomplish this, I instantiate a request scope object that keeps the request context. And before everything gets disposed (at AppHost's OnEndRequest handler), I write to the db. One line per http req.
I'm able to access the response code, the path, the method, request body, request headers, etc.
However the response stream is not available as it was already disposed. What's the logic behind this? Is it something like, IIS writes the stream content to the wire, and releases the resource imediately? Is there any way I can capture the Response body at the OnEndRequest handler?
Thanks
No, ServiceStack doesn't buffer the Response stream it gets written directly to the ASP.NET response.
You can add a Global Response Filter or Custom ServiceRunner to capture the Services response if the request reaches that far, but the request can be short-circuited at anytime throughout the request pipeline by closing the response.
I had the same issue with capturing the response in ServiceRequestLogger. Read this post - it is solved in 4.0.39+ (currently pre-release)
ServiceStack response filter "short circuiting" causing problems
Related
We are developing a chatbot to handle internal and external processes for a local authority. We are trying to display contact information for a particular service from our api endpoint. The HTTP request is successful and delivers, in part, exactly what we want but there's still some unnecessary noise we can't exclude.
We specifically just want the text out of the response ("Response").
Logically, it was thought all we need to do is drill down into ${dialog.api_response.content.Response} but that fails the HTTP request and ${x.content} returns successful but includes Tags, response and the fields within 1.
Is there something simple we've missed using composer to access what we're after or do we need to change the way our endpoint is responding 2? Unfortunately the MS documentation for FrwrkComp is lacking to say the very least.
n.b. The response is currently set up as a (syntactically) SSML response, this is just a test case using an existing resource.
Response in the Emulator
Snippet from FwrkComp
Turns out it was the first thing I tried just syntactically correct. For the case of the code given it was as simple as:
${dialog.api_response.content[0].Response}
My application is running an Express http server. I need to save the whole http request message (headers, body,..) in its raw format just as was sent by the client to the server. I can’t find Where it is stored. Any one?
The whole thing isn't stored anywhere. Express uses the http module in node.js which parses the incoming request and headers into a data structure. The body of the request (like for a POST or a PUT) is left to you to read from the incoming readstream so you can certainly read the exact body yourself. Just hook up a listener for the data event on the incoming request stream and you can read the exact bytes of the body right into a Buffer object.
You could reconstitute the http command line and all the headers if you want from the data structure, but I don't think that original data is stored exactly as it arrived.
Some of the information is in these properties as documented here:
request.rawHeaders
request.method
request.httpVersion
request.headers
request.url
If you can explain exactly what the actual problem is that you're trying to solve, we'd have a better idea exactly how else to help you.
If I understand correctly, a preflight OPTIONS request is sent as a way of asking "what's allowed here?". Then, once the response comes, if allowed, the calling site sends the POST request (or GET but in my case it's a post). I have figured out that, at least with Azure Function Apps, the OPTIONS request is executing the code that I expected only the POST to execute. I believe this to be the case because once I added some null checking (since the OPTIONS request doesn't have a payload in the body) everything worked fine.
I'm wondering if this is standard.
Seems to me that if I had written the API without using Azure Function Apps, I'd have the OPTIONS request sent down a path that would set the appropriate headers and return a 200 response. And the POST request would be sent down a different path that would expect a payload in the body. If that's how it usually works then that means I've just found an idiosyncrasy of the Azure functionality. But if not it means that I have something to learn about the OPTIONS preflight request.
Thanks in advance for your advice.
Denise
As sideshowbarker mentioned, the OPTIONS request is sent automatically by the browser to check if the cross-origin request can be made.
In case of Azure Functions, this will handled by the Azure when running in the cloud.
If your function is being triggered, that would mean that you have "options" as a supported method for your HTTP Trigger
In the HTTPTrigger attribute for C# functions
In functions.json for non-C# functions
If you want to customize the CORS responses and/or running functions in a container, you could always include "options" as supported and respond differently when the incoming HTTP method is OPTIONS.
Also, if you are using Azure API Management with Azure Functions, you could offload CORS handling to it instead or even use Functions Proxies as shown here.
Thanks y'all! Sorry I was unclear. And sorry it took me a while to get back. Things have been a bit crazy on this end.
Yes, the function being called is mine. And now I understand the browser doesn't have much choice as to whether or not it makes the OPTIONS call.
And yes, I could make my Azure function handle an options call differently and thanks for that suggestion too. That's sort of what I ended up doing but basically I did it by handling an empty payload. I didn't follow that best practice originally because I thought any valid request would have a payload. Accordingly, any request that did not have a payload was invalid and should be turned away as a failure of some sort. This was before I knew that the OPTIONS call was actually executing that function.
My remaining question is if I had NOT been using Azure... if I had rolled my own solution and hosted it somewhere, I'd have a class or at least methods that handle calls to this particular API. (This is something I'm new to so bear with me if my terms aren't quite right and please do correct me). So if I'd done my own API, I'd have one method to handle a POST call and a different method to handle an OPTIONS call, wouldn't I? And the method that handles the OPTIONS call would return information about what's legally do-able with this API. And the method that handles a POST call would handle the payload sent with it. And the method that handles the POST wouldn't get executed when an OPTIONS request is sent. At least that's how I figured it would work. And that's my question -- is that how it's done when not letting something like Azure handle some of the infrastructure?
I'm just trying to learn if the OPTIONS request executing a POST's function is a standard practice or if it's some kind of idiosyncrasy to working with Azure functions.
Thanks again for the advice and for helping me understand these questions.
I'm pretty new here, so hope I can get some help with a basic doubt which I couldn't get around yet.
I'm using NodeJs and I have followed the Rabbiq GetStart and could understand the flow, however my doubt is with regards Http request.
What I need:
Manage http (POST, PUT, GET, DELETE) requests to another server.
What I was expecting:
RabitMQ manage the request QUEUE, so if some request fail it would retry again. When its successful, it would call another API on my end to flag the request was successfull.
What is my question:
I couldn't find any example which I would setup this request, providing the sender URL, METHOD and PAYLOAD and also the callback URL, METHOD, HEADERS, and PAYLOAD.
Is that something related to RabbitMQ or am I getting it wrong?
Is it possible to validate if an HTTP request originated from the client as GET, but was intercepted in between and converted to POST, or vice versa?
It is one of the security validations that is required as part of the project I am working on, but not getting enough clue about it. One of the way we thought of using as validation is to check if it is a GET request with a body than it could be POST. But that is just one case. Also if a POST is changed to GET by forging the request, I believe the data in the body can also be removed.
edit: Added more information about application and the intercepter
It is a regular Java web application developed using Struts with JSPs on the client side. The request from the web pages are being intercepted using Burp Suit Proxy to change the payload in the request.