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.
Related
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.
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?
I have a domain from Namecheap.com and hosted a page through github pages. Sometimes the my page fails to load and gives "too many redirects" error. I think the problem in somewhere in my advanced DNS. Take a look at it-enter image description here
Basically I have got 2 A records pointing to the IP address of Github and a CNAME record pointing to mygithubusername.github.io and an URL redirect record pointing to my domain. What am I doing wrong?
As far as I can see the problem comes from the URL redirect record. When trying to reach www.akshayud.me it redirects to akshayud.me and when it hit the URL redirect it redirects back to www.akshayud.me, which redirects to akshayud.me and is making an infinite loop.
To solve it remove the URL record from the DNS (which is my preferred solution) or fix the redirection from www to root on web server level.
Here is my wget output (I used only the URL record IP to guaranty 100% usage of the URL redirect record):
$ wget www.akshayud.me
--2017-12-19 08:03:18-- http://www.akshayud.me/
Resolving www.akshayud.me (www.akshayud.me)... 151.101.1.147, 151.101.65.147, 151.101.129.147, ...
Connecting to www.akshayud.me (www.akshayud.me)|151.101.1.147|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://akshayud.me/ [following]
--2017-12-19 08:03:18-- http://akshayud.me/
Resolving akshayud.me (akshayud.me)... 162.255.119.148
Connecting to akshayud.me (akshayud.me)|162.255.119.148|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.akshayud.me/ [following]
--2017-12-19 08:03:18-- http://www.akshayud.me/
Connecting to www.akshayud.me (www.akshayud.me)|151.101.1.147|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://akshayud.me/ [following]
--2017-12-19 08:03:18-- http://akshayud.me/
Connecting to akshayud.me (akshayud.me)|162.255.119.148|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.akshayud.me/ [following]
--2017-12-19 08:03:19-- http://www.akshayud.me/
Connecting to www.akshayud.me (www.akshayud.me)|151.101.1.147|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://akshayud.me/ [following]
I had the same issue, and the solution was for me that in my github CNAME file, I had to change my webpage title. So after I changed it to "www.mywebpage.hu" (before it was without "www."), then no more redirect problems happened. I've checked your CNAME, and you don't have 'www.' too, maybe it will help if you complete your title with this.
I got into the same trouble and in my case,
How I Fixed :
the mistake was in my CNAME record. I pointed CNAME www to my github pages domain (username.github.io), so when I hit the domain it creates a loop of github domain -> custom domain -> github domain ..... as github domain auto redirects to the custom domain. Changing the CNAME value to my custom domain fixed the issue
I am building an api with flask-restful and an ionic/angular mobile app, but requests to the api are failing with the error "XMLHttpRequest cannot load http://localhost:5000/api/v1/auth. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access. The response had HTTP status code 400." even after specifying the Access-Control-Allow-Origin header in the Resource response.
class Auth(Resource):
def post(self):
#some code here
return responseObject,200,{'Access-Control-Allow-Origin':'*'}
I have tried different browsers and when i check the network XHR calls the response headers don't show the it.
Content-Length:90
Content-Type:application/json
Date:Thu, 14 Sep 2017 11:46:25 GMT
Server:Werkzeug/0.12.2 Python/2.7.10
Yet when i use postman to send the requests, i see the Access-Control-Allow-Origin header
acccess-control-allow-origin →*
content-length →198
content-type →application/json
date →Thu, 14 Sep 2017 12:54:52 GMT
server →Werkzeug/0.12.2 Python/2.7.10
Anyone with an idea of what is happening, i will be glad to receive your help.
thanks in advance.
I think that you have to allow cross origin calls in your API. Have a look here : http://flask-cors.readthedocs.io/en/latest/
I am trying to test a Rest service through HTTP sampler using Jmeter. The first sampler generates a token and I am using this token for authorization in the header manager of another HTTP sampler "GetUserandPolicies"(Rest WS request) using RegEx and ForEach controller. I can see in the view results tree that RegEx is working fine passing the actual token to the next request. But the Rest Request is failing giving a response message as Forbidden and Response Code 403 which means that the server is able to recognise the request but denying the access.There is no port number for this HTTP sampler which I suspect would be the culprit. But, the same test is passing with another tool (iTKO LISA) without any port value. Both the samplers "TokenGeneration" and "GetUserandPolicies" have no port values. I need some help on this. I am using the POST method in the HTTP sampler
Please find the sampler result:
Thread Name: Thread Group 1-1
Sample Start: 2014-01-13 12:12:29 IST
Load time: 1390
Latency: 1390
Size in bytes: 382
Headers size in bytes: 354
Body size in bytes: 28
Sample Count: 1
Error Count: 1
Response code: 403
Response message: Forbidden
Response headers:
HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Authorization, X-Requested-With, Content-Type
Content-Type: text/plain;charset=UTF-8
Content-Length: 28
Date: Mon, 13 Jan 2014 06:42:30 GMT
HTTPSampleResult fields:
ContentType: text/plain;charset=UTF-8
DataEncoding: UTF-8
Looking into Access-Control-Allow-Headers: Authorization, X-Requested-With, Content-Type stanza I guess that you're missing proper Authorization header.
In regards to empty port everything is fine, it defaults to port 80 in case of HTTP and 443 in case of HTTPS
There are 2 options on how you can deal with Basic HTTP Authentication:
Pass username and password in URL like protocol://username:password#host:port/path
i.e. http://user:pass#your.server.com/somelocation
Use JMeter HTTP Authorization Manager to construct required "Authorization" header for you.
In case if your authentication system uses other approaches, i.e. Cookie-based, NTLM or Kerberos it's still possible but a little bit more tricky. If so - update this post with all details you can get (i.e. request details) and don't hesitate to leave a comment requesting for more input