spring gateway always returns 301, how to continue processing - spring-cloud

This is clarification of the OP
I have a spring gateway that uses eureka server to route requests to registered spring boot eureka clients.
What I am seeing is that every request results in a 301 redirect containing a Location header. It seems that because the request is received on https://my-api.io/payment/payment-intent spring-gateway looks it up based upon these rules:
server.forward-headers-strategy=framework
feign.hystrix.enabled=false
spring.cloud.config.discovery.enabled = true
....
spring.cloud.gateway.routes[11].id=orders-service
spring.cloud.gateway.routes[11].uri=lb://orders-service
spring.cloud.gateway.routes[11].predicates[0]=Path=/payment/**,/order/**
spring.cloud.gateway.routes[11].predicates[1]=Method=GET, POST
spring.cloud.gateway.routes[11].predicates[2]=Header=APIKEY, (.*)
spring.cloud.gateway.routes[11].filters[0]=AuthorizationHeaderFilter
## these next two apparently have no impact
spring.cloud.gateway.routes[11].filters[1]=RewritePath=/(?<segment>.*),/payment/$\{segment},/order/$\{segment}
spring.cloud.gateway.routes[11].filters[2]=RedirectTo=301, lb://orders-service
And then returns the Response Headers:
Server: awselb/2.0
Date: Tue, 24 Jan 2023 17:58:36 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://my-api.io:8081/payment/payment-intent
If I enable "follow redirects" in Postman or curl, then it works fine. But that won't work in a mobile app, so I really need to have spring-gateway just route the call on first pass. I don't know if this is because the routes.uri defines the as coming from the load-balancer (since ports are dynamic and there are likely multiple instances) url so it seems like a different url or what.
I am desperately trying to find a way so that the request is just processed and not bounced back with a 301.

Now that I have context around the issue it turns out the issue was not with Spring Gateway since its just a passthru (after some validation). Thanks to spencergibb I was able to rule out gateway and realize it was a forwarding issue in AWS.

Related

How can I find out why ISAPI is returning a 302 status for a specific file?

I have a website hosted served by IIS 10 on a Windows Server (2019) running Plesk. The site is mainly Classic ASP. I have a staging subdomain at staging.example.com, with the production site at www.example.com.
The two are fairly strictly separated, except that I don’t store image files, PDFs and such things on the staging server; I have a URL rewrite directive that redirects to the production site with a 302 status based on the URL not matching the following regex:
\.(php|asp|js|css|csv|json|htm|html|svg|svgz)(\?.+)?$
This generally works well: ASP pages are served from the staging site when the staging URL is called, but images on the page are pulled from the production site.
Except that there’s one ASP file which – for some reason – gives a 302 and redirects to the production site no matter what I do. The file exists in both locations. I’ve tested the URL in the pattern tester provided in the IIS URL-rewrite section, and it matches the pattern (meaning it shouldn’t redirect).
When I trace the request (that is, the initial request to the staging URL) in Firefox’s browser console, I get the following response headers (redacted):
HTTP/2 302 Found
cache-control: no-cache
content-type: text/html
location: https://www.example.com/path/to/file.asp
server: Microsoft-IIS/10.0
set-cookie: ASPSESSION****=********; secure; path=/
x-powered-by: ASP.NET
x-powered-by-plesk: PleskWin
date: Sun, 19 Dec 2021 18:52:05 GMT
content-length: 201
Accept
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding
gzip, deflate, br
Accept-Language
en-US,en;q=0.5
Authorization
Basic *************
Connection
keep-alive
Cookie
[cookies]
Host
staging.example.com
Referer
https://staging.example.com/path/to/file.asp
Sec-Fetch-Dest
document
Sec-Fetch-Mode
navigate
Sec-Fetch-Site
same-origin
Sec-Fetch-User
?1
Upgrade-Insecure-Requests
1
User-Agent
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0
I’ve painstakingly gone through the entire file and all the file includes within it, and I can’t find any kind of Response.Redirect in any of them that might be responsible.
So it seems it’s IIS that’s redirecting with a 302… despite the fact that there doesn’t seem to be a directive that tells it to do this.
Is there a way to trace exactly what on the server is causing this 302 for one specific file? Some sort of tracing mechanism that tells me where the request gets passed on to before the 302 response is returned?
 
 
Update 26 Dec
Based on samwu’s comment, I’ve enabled Failed Request Tracing for the page, and looking through the resulting .frb file, it’s clear that none of the rewrite conditions are met – they all have succeed: false. It seems the redirect is not happening in the WWW Server at all, in fact, but in the ISAPI extension. This is the only place that the production site URL is mentioned at all in the request trace (except of course in the GENERAL_RESPONSE_HEADER section at the very end):
ISAPI_START
MODULE_SET_RESPONSE_SUCCESS_STATUS ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="302", HttpReason="Object moved"
GENERAL_SET_RESPONSE_HEADER HeaderName="Location", HeaderValue="https://www.example.com/path/to/file.asp", Replace="false"
GENERAL_SET_RESPONSE_HEADER HeaderName="Content-Length", HeaderValue="201", Replace="false"
GENERAL_SET_RESPONSE_HEADER HeaderName="Content-Type", HeaderValue="text/html", Replace="false"
GENERAL_SET_RESPONSE_HEADER HeaderName="Cache-control", HeaderValue="no-cache", Replace="false"
NOTIFY_MODULE_COMPLETION ModuleName="IsapiModule", Notification="EXECUTE_REQUEST_HANDLER", fIsPostNotificationEvent="false", CompletionBytes="0", ErrorCode="The operation completed successfully. (0x0)"
ISAPI_END
In the ISAPI Filters section in IIS Manager, there are four filters: a 32-bit and a 64-bit version for ASP.Net 2.0 and the same for ASP.Net 4.0, all called aspnet_filter.dll. I’m guessing these are standard filters – I know for certain, at least, that we haven’t mucked about with any ISAPI filters at all.
As should be obvious by now, I’m not really a server admin, and ISAPI filters are definitely above my level of knowledge.
So how do I proceed from here? How do I figure out why ISAPI is redirecting?

Cross-Origin Request - "Same origin" blocked on GET request

I'm trying to deploy a SAILS app & a VUE app on heroku with a custom domain. I'm currently facing with something that seems to be a CORS issue, but I do not understand this one.
Problem
When I send a GET request to my backend in stage mode, (with postman or my frontend-app) I get an error message :
"... blocking Cross-Origin Request : the "same origin" policy does not
allow access to the resource located at
https://app-frontend.herokuapp.com/api/v1/account/user-controller
...".
The HTML response is :
Status 503 →Service Unavailable
Cache-Control →no-cache, no-store
Connection →keep-alive
Content-Length →511
Content-Type →text/html; charset=utf-8
Date →Tue, 24 Jul 2018 08:17:13 GMT
Server →Cowboy
And my sails console gives me this info :
Redirecting GET request from 'undefined.' subdomain...
But with POST requests, I don't face to this problem and my route is well defined as it works in dev mode.
Did you try setting csrf: false in the config/security.js? It shouldn't affect GET requests, but the key to your problem might be somewhere there.

301 moved permanently with socket.http

In python (and my browser), I am able to send a request to https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0 and get a response, as expected, but with Lua, I get HTTP/1.1 301 Moved Permanently. Here is what I have tried so far:
http = require("socket.http");
print(http.request("https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0")
which outputs an HTTP error page (moved permanently) and
301 table: 0x8f32470 http/1.1 301 Moved Permanently
the table's contents are:
location https://www.devrant.com/api/devrant/rants?app=3&sort=algo&limit=10&skip=0
content-type text/html
server nginx/1.10.0 (Ubuntu)
content-length 194
connection close
date Mon, 11 Dec 2017 01:41:35
Why does only Lua get this error? If I request to google, I get the google home page HTML. If I request to status.mojang.com, I get the mojang server statuses in a JSON response string, so the socket is functional for certain.
It's because you are using socket.http to request a page from https URL; since socket.http doesn't handle https, it sends the request to port 80, which gets forwarded to https URL, but socket library doesn't follow that redirect, as it doesn't "know" what to do with https, so it simply reports 301.
You need to install and use luasec and use ssl.https instead of socket.http, which will make it work.

Haproxy behind ELB

I have HAproxy is behind an AWS ELB. As soon as i remove the ELB, i can get the custom error page. but, with ELB in the front of Haproxy, i get HTTP/1.1 504 GATEWAY_TIMEOUT Content-Length: 0 Connection: keep-alive.
Can anyone tell me what is going on please? Thanks
errorfile:
HTTP/1.0 403 Forbidden
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>
Me and a coworker just had the same problem. After receiving the timeouts, and reading amazon definition for this type of http code, i got in my head my error file was "malformed". After a lot of trys, we managed to discover that there is something funny with the CL-RF (new lines) on the error file "header".
I downloaded HaProxy default file from their git (https://raw.githubusercontent.com/haproxy/haproxy/60220bbc4b6b3c4279d3c96232cf2c2461ecc55e/examples/errorfiles/503.http) and when you open it on vi(m) it has a ^M (CR) sign on the headers(everything before the body, including the empty line separating them). If you cant download it, you could just write it (just the top part) on wordpad or something like it (dos) and then send it to you unix machine.
So i wrote my on file using their header and now everything works fine.
Cheers.

OSB - Processing Http errors from Restful service in Proxy Service

I'm invoking a REST service from an OSB Proxy Service, which is working fine if the rest service response is a valid response, i.e., there's no errors. However if the rest service replies with an http error code (e.g. 400 Bad Request), I'm not able to capture anything else except the http error code:
$fault variable in OSB:
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-382502</con:errorCode>
<con:reason>
OSB Service Callout action received an error response
</con:reason>
<con:details>
<con1:ErrorResponseDetail xmlns:con1="http://www.bea.com/wli/sb/stages/transform/config">
<con1:http-response-code>400</con1:http-response-code>
</con1:ErrorResponseDetail>
</con:details>
<con:location>
<con:node>PipelinePairNode1</con:node>
<con:pipeline>PipelinePairNode1_request</con:pipeline>
<con:stage>stage1</con:stage>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
But the rest service, is not only replying with 400 Bad Request, but also adding a message:
<Error>
<Message>The message header contains an invalid brand code.</Message>
</Error>
Which I'm not able to process in my proxy service. Does anyone knows if it is possible to access this message details in OSB or is it a limitation?
The rest service is clearly sending the message, because invoking it directly through soap-ui I'll get the following response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 84
Content-Type: application/xml; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 09 Feb 2015 16:15:32 GMT
<Error><Message>The message header contains an invalid brand code.</Message></Error>
Thanks
I've just found out this is an OSB bug, in case of an HTTP Error code 400 being returned, if the http-content is "Application/XML" the message is ignored.
Oracle released a Patch at the end of last month to fix this issue, which I've tested and it works. I can get the message details in the $body variable now.
Patch: 16986497
If I understand your question, you want to get in addition to the http code, the message error?
I think you should use, in your message flow, an errorHandler , so that you can catch the error and do whatever you want with.
The proxy service operation selection algorithm cannot determine the operation name from the request or returns an invalid operation (one which is not in the WSDL or null). Possible reasons include the following:
An error occurs while computing the operation.
The operation selection algorithm returns null.
The operation selection algorithm returns an operation that is not of the of the operations declared by the WSDL.
Source