there's next site - vten.ru
When I try to make GET request with Postman to it, I give in return status code 304 Not Modified.
Code on Phyton:
import requests
url = "http://vten.ru"
payload = ""
headers = {
'cache-control': "no-cache",
'Postman-Token': "29ae741a-1c31-4a52-b10e-4486cb0d6eb7"
}
response = requests.request("GET", url, data=payload, headers=headers)
print(response.text)
how can I get the page?
You presumably already have a version of the request cached, hence the "Not Modified" response indicating that the response hasn't changed since you last requested it.
EDIT:
Viewing that site/inspecting the network activity via Chrome shows that the document returned is actually http://m.vten.ru. You should try making your GET request to that URL instead.
You also need to add the Accept: text/html header to your request. That returns the page you want having just tested it locally.
Related
There are two pics, the first is send request in the brower, etag value always same and http status always 200 ok, base on the http etag stretegy, I would get the 304 not modified in this request. Then what make me doubt is when I copy the request as curl run in the bash, it worked, server return right 304 not modified.
My server side is Spring Boot, relate code is
#Bean
fun shallowEtagHeaderFilter(): ShallowEtagHeaderFilter? {
return ShallowEtagHeaderFilter()
}
Front side is react with axios, relate code is:
import axios from "axios";
const request = axios.create({
baseURL: 'http://localhost:8082',
timeout: 10000,
withCredentials: true
})
export default request
I waiting for you response online, thanks for yous reading.
Click View source button in the Response Headers part, maybe you will see HTTP/1.1 304 Not Modified.
I don't know why Chrome shows status code 200 in General part.
A similar question: Why Chrome Dev Tool shows a 200 status code instead of 304
And I tried my code in Firefox, the status code is 304.
I'm working with an API with a web hook. i need to send back a 401 to trigger the proper logic. But my code is giving the error:
Misused header name. Make sure request headers are used with HttpRequestMessage, response headers with HttpResponseMessage, and content headers with HttpContent objects.
This is my code to send a 401 response:
HttpResponseMessage response = new HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized);
response.Content = new StreamContent(new MemoryStream(),327);
response.Content.Headers.Add("WWW-Authenticate", "Basic realm=\"myCloud\"" );
response.Content.Headers.Add("Content-Type", "application/xml");
return response;
What is the issue with the headers? The error implies that the headers are not intended for a HTTP Response, but a Request. But I don't get it since this is how the other API is designed to work -- it expects a 401 RESPONSE with the www-authenticate header.
This is being returned from an Azure HTTP triggered Function (over HTTPS) (if that makes any difference). I'm trying to understand if I can ignore the error or if I am breaking some HTTP rules here?.
I'm hitting an API using http dart library while doing this I'm getting 302 status code. I know that 302 status code is for redirects, can you please say how can i enable redirects in http post method. I have used the following code:
Future<LoginModel> login(String username, String password) async {
var client = new http.Client();
final response =
await client.post(LOGIN_URL +"username=Student&password=2018" ,
headers: {'Content-type': 'application/json',
'Accept': 'application/json'});
if (response.statusCode == 200) {
return LoginModel.fromJson(json.decode(response.body));
} else {
throw Exception('Failed to load post');
}
}
302 is a status code returned by the server to indicate that the client should retry the request using a different URL. It's a way to redirect the client to a different endpoint.
The problem is that only GET (or HEAD) requests can be retried automatically. You are using a POST.
If the 302 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
A well-behaved API should probably not issue 30X in response to a POST, but it is. The way to get around this is to make a new http request with the redirected URL. (You might want to put it in a while loop to keep following the redirects until you get to 200, or some error, or reach a timeout/limit.)
add header with
"Accept":"application/json" . henceforth it will only return json data otherwise it will prompt to redirect with html url, default dio configuration does not have response type so you have to mention it in header.
This is because of some issue with the URL that you use. status code 302, says that the URL you are using has been moved or redirected.
May be the loginurl that you are using has certificates now and using https:// instead of http://
I've read https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication and the Basic Authentication chapter from HTTP: The Definitive Guide.
I thought Proxy-Authenticate + Proxy-Authorization + status code 407 was essentially the same as WWW-Authenticate + Authorization + status code 401. I thought if the server responded WWW-Authenticate + 401 or Proxy-Authorization + 407, under both conditions, the browser would pop up an auth dialog, and then the browser would send the credentials with the Authorization or Proxy-Authorization header.
The "WWW-Authenticate combination headers" did work as expected, while the "Proxy combination headers" did not. For Proxy-Authorization + 407, I get ERR_UNEXPECTED_PROXY_AUTH in Chrome and get nothing happened in Firefox(No auth dialog popping up!).
Error in Chrome:
This site can’t be reached.
The webpage at http://localhost:5000/http_auth might be temporarily down or it may have moved permanently to a new web address.
ERR_UNEXPECTED_PROXY_AUTH
So what's the difference between these 2 sets of similar headers? When and where do I use Proxy-Authenticate? Practical exmaples that I can run would be much appreciated.
I am using Python with Flask for testing.
My serverside code:
WWW-Authenticate
#app.route('/www_auth')
def ha():
print("====request headers begin======")
print(request.headers)
print("====request headers end======")
if 'Authorization' in request.headers and request.headers['Authorization'] == 'Basic MTIzOjQ1Ng==':
return render_template('demo.html')
else:
resp = make_response(render_template('demo.html'), 401)
resp.headers['WWW-Authenticate'] = 'Basic realm="WWW-Authenticate required :)"'
return resp
Proxy-Authenticate
#app.route('/proxy_auth')
def haha():
print("====request headers begin======")
print(request.headers)
print("====request headers end======")
if 'Proxy-Authorization' in request.headers and request.headers['Proxy-Authorization'] == 'Basic MTIzOjQ1Ng==':
return render_template('demo.html')
else:
resp = make_response(render_template('demo.html'), 407)
resp.headers['Proxy-Authenticate'] = 'Basic realm="Proxy-Authenticate required :)"'
return resp
I did some tests and here's what I found. (I took a look at RFC and as usual it's too overwhelming :) )
The Proxy-Authenticate set of headers can indeed result in auth pop-up dialog too. But it is something that one must manually set in the client/browser at first. Specifically, for example in Firefox, it's related to the proxy setting.
The Proxy-Authenticate set of headers is used when you connects to a proxy which needs username and password.
Attention: You need to set the root path to your proxy function like this:
#app.route('/')
def haha():
#rest of the code
The workflow is:
-----------------------------------Step 1---------------------------------------------------->
client/browser <---Step 2, 407,Proxy-Authorization response header, required username and password----------- proxy
----Step 3, Proxy-Authorization request headers, contains credentials------------------------> --------> target website
----Subsequent requests, Proxy-Authorization request headers with credentials is still sent--> ---------> target website
In this case, the Proxy-Authorization(with credentials) will be sent automatically for each request.
If the server does not require authentication, then the client can visit the target website directly, and there's no Proxy-Authorization header in the request. (Most free http proxies that you find on the Web works in this way I think)
I also tried the WWW-Authenticate set of headers while I had set the proxy setting in Firefox. The result is that: Every time I visit a new website, I need to authenticate again. So obviously the WWW-Authenticate set of headers aren't meant to be used in this case.
Any other in-depth opinions/explanation would be appreciated. After all I merely did some tests and I want to know more.
I need to make an HTTP GET request with custom request headers in-browser and process the result as it streams in. The Fetch API is ideal for this:
fetch('https://example.com/resource', {
method: 'GET',
headers: {
'X-Brad-Test': 'true'
},
cache: 'no-store',
mode: 'cors'
}).then((res) => {
const reader = res.body.getReader();
// etc.
});
This works quite well. Since there are custom headers, the browser pre-flights the request with an OPTIONS request to /resource. I have configured my server to respond with a 204 No Content and the following headers:
Access-Control-Allow-Headers: X-Requested-With, Range, If-Range, X-Brad-Test
Access-Control-Allow-Origin: *
The browser is happy with this, then makes a GET request, the server returns a 200 OK with the data, and the browser allows me to access the response headers and body.
The problem comes in when there is a redirect. The OPTIONS request succeeds with the 204 No Content and the same headers as before. The browser makes the correct GET request, and on the server I send a 302 with a Location: header. Chrome throws the following error:
Fetch API cannot load https://example.com/resource. Redirect from 'https://example.com/resource' to 'http://some-other-origin/resource' has been blocked by CORS policy: Request requires preflight, which is disallowed to follow cross-origin redirect.
This was unexpected, and seems nonsensical to me. I expected the browser to follow the redirect, and do another pre-flight request for this new location, but it didn't do that.
Stranger still is that I can sort of hack around this client-side. I can make an HTTP request without my custom header, figure out where I ended up after redirects by looking at the Response object, then make a second request at the new target with my custom headers. This doesn't work in all cases of course, and I'd rather not rely on this hack. I'd rather find a proper way.
Two Questions:
What is the proper way to allow the client to follow redirects? Is there some sort of Access-Control-* header I can use?
Why does this restriction exist? What security issue is prevented by not following and running pre-flight on the followed URL?
Supporting redirects to requests that require a preflight is very recent change to Fetch (which defines CORS).
https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2
I believe some implementations have started adjusting their implementations, but this will take some time to reach everyone.