parsing http referer in cloudwatch - http

I am currently running a query in cloudwatch aws but I can't figure out how / if I actually can parse information about requests http referer data on an application im running. Is anyone able to asssit me on this?
I read cloudwatch documentation and tried running some querys blindly but unable to parse any http referer data

Related

How to make a request to a URL with gRPC Transcoding Syntax with a standard POST request?

I am attempting to use the endpoint https://firestore.googleapis.com/v1/{parent=projects/*}/databases with more data needed per the documentation on Google's docs.
The goal is to be able to make this request with a standard http utility such as cURL.
I have attempted performing the request manually through the GUI with the Chrome network tab open, and I saw a request being made: https://firebasedatabase.clients6.google.com/v1beta/projects/XXXXXXXXXX/locations/us-central1/instances?databaseId=my-database&validateOnly=true&alt=json&key=secretkey
Per trial and error on another endpoint, I have found that the key parameter can be replaced with a Bearer Auth token in the header. Other than that I am at a dead end.

400 Bad request while consuming a rest service with POST method?

I'm getting http requestor connection problem with POST:request a bad request even though I'm configuring properly. I'm sending json payload in the body and Bearer token in headers parameters with content type, I can evaluate the token and payload properly but still getting as a bad request when I tried to hit the direct URL as well, and I tried the trigger in postman with the same token generated in mule where I'm getting the success response but while using the same service within mule getting as bad request, I'm using http connector plugin version 1.7.1 in pom.xml.. Is there any problem with the dependency? can anyone help me with this?
If you are successful doing the request in postman then the HTTP request in your Mule application has to need some adjustments to make it match the postman request. Compare them carefully to make them match.

how to fix the bug found during SOAPUI security testing

I was doing a automation testing on my web application with SOAPUI, I have found a bug which is http method fuzzing basically it means "HTTP Method Fuzzing
An HTTP Method Fuzzing Scan attempts to use other HTTP verbs (methods) than those defined in an API. For instance, if you have defined GET and POST, it will send requests using the DELETE and PUT verbs, expecting an appropriate HTTP error response and reporting alerts if it doesn't receive it.
Sometimes, unexpected HTTP verbs can overwrite data on a server or get data that shouldn't be revealed to clients."
Can anyone knows how I can solve this issue or how I block the HTTP request other than GET or POST which may remove this bug.
I am using Node.js and express for my web application.
Please check the images:
Image 1
Image 2

HTTP 400 on S3 static file

We've spotted (in our error tracking tool) some http 400 issues while fetching some static files.
Also, there are logs in our API gateway regarding that it redirected the request to S3 which responded 400.
It's not our CDN neither our API gateway.
Why would S3 respond 400 to a static file?
We couldn't find anything exactly about it anywhere so far, but some general resources about 400 were pointing to issues with some HTTP header:
Malformed request syntax
If-Modified-Since
Amazon ALB 400 Request header or cookie too large
Kong 400 Request header or cookie too large
Since we couldn't manually reproduce that accessing our system, we started trying to fetch the static files with some unexpected headers using Postman.
We finally could quickly reproduce the issue by sending huge Cookies.
Our hypothesis is that, probably, Amazon S3's static website has some configuration that blocks requests with some specific long headers/cookies.
Once we couldn't find a way to configure that on S3, we've added a plugin to our API Gateway that when it was a static file request, it would remove the cookie before redirecting it to S3 (it wasn't required).
After that change, we've monitored our error tracking tool, and the occurrences of http 400 on static website dropped to 0.
Today I just got kind same case, my case reason is the cookie side is too big.

Partial Response received from Apigee

The flow is SAP NWAS 7/Java AS ---> Apigee On Premise--->Apigee OnCloud -----> Backend. and back.
Backend is posting a response of appx 17 MB back. I have streaming enabled both on cloud and on premise Apigee. But the sap NWAS client states that only partial response is received .
When we invoke from POSTMAN however, we are getting complete response.
Please suggest where the problem can be?
Since Postman works fine for you, it seems like it might be a problem on the client side. So, it's possible that the client requires more info on the response in order to be able to display the content e.g. Content-Type header. Another way to troubleshoot this issue is to send a cURL command to the resource in Apigee and store it in the filesystem to validate that not only Postman can parse the response. e.g.
curl http://yourresourcehere/images/12344 > img12344.png

Resources