I have a Django website with activated translations (django.middleware.locale.LocaleMiddleware),
I someone requests a non-existing page:
https://example.com/nonexisting
Django then responds with:
HTTP/1.1 302 FOUND
Date: Fri, 02 Sep 2016 09:15:45 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: Cookie,Host
Location: https://example.com/de/nonexisting
Content-Type: text/html; charset=utf-8
HTTP/1.1 301 MOVED PERMANENTLY
Date: Fri, 02 Sep 2016 09:15:45 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: Cookie,Host
X-Frame-Options: SAMEORIGIN
Content-Language: de
Set-Cookie: django_language=de; expires=Sat, 02-Sep-2017 09:15:45 GMT; Max-Age=31536000; Path=/
Location: https://example.com/de/nonexisting/
Content-Type: text/html; charset=utf-8
HTTP/1.1 404 NOT FOUND
Date: Fri, 02 Sep 2016 09:15:45 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: Cookie,Host
X-Frame-Options: SAMEORIGIN
Content-Language: de
Set-Cookie: django_language=de; expires=Sat, 02-Sep-2017 09:15:45 GMT; Max-Age=31536000; Path=/
Content-Type: text/html; charset=utf-8
The user receives in this order:
302,301,404
How can I achieve that the user directly gets the 404?
Related
I have a django application (version 4.0.3) and I want to URL MASK some specific URLs using new purchased domains (in this case GoDaddy)
So what I want to do is:
www.originaldomain.com/url1 beeing masked with www.newdomain.com.
But when I redirect with mask in domain www.newdomain.com some HEAERS do not allow it (I know because GoDaddy tech support said me "something is blocking it").
If I do a normal redirect (301 or 302) it works, but not with URL Masking.
I tryied removing X-Frame-Option: Deny using a django decorator to the view but still not able to make it work.
Current response headers
HTTP/1.1 200 OK
Date: Fri, 22 Jul 2022 06:47:40 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Cookie, Accept-Language
Content-Language: es
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
Set-Cookie: csrftoken=UJp7VSdbT7BnFmc9wKnFZeKSKWjtGbLcEaLEqrZ0MAj8NhU69MDjZQIgWj5LhnWw; expires=Fri, 21 Jul 2023 06:47:40 GMT; Max-Age=31449600; Path=/; SameSite=Lax
Set-Cookie: sessionid=bjtb3e42z9h9wd5tixsw3xpj23kiao1u; expires=Fri, 05 Aug 2022 06:47:40 GMT; HttpOnly; Max-Age=1209600; Path=/; SameSite=Lax
X-Clacks-Overhead: GNU Terry Pratchett
Content-Encoding: gzip
Server: PythonAnywhere
An explanation of how to find what is blocking it would also be very appreciated (like using
I'm trying to login through the http form, from DRF:
> https://my.site.io/api-auth/login/
Using httpie, i generate a session.json to get the CSRFToken:
$ http --session=why -h https://my.site.io/api-auth/login/
Referrer-Policy: same-origin
Server: nginx/1.18.0
Set-Cookie: csrftoken=dT2UuBjp7Xei2iqzmD9A9lNNaTZO8ZHHPh098I8mV27v56E0jePTPgQ0KC3LDmpE; expires=Thu, 02 Dec 2021 15:32:49 GMT; Max-Age=31449600; Path=/; SameSite=Lax
Vary: Cookie
X-Content-Type-Options: nosniff
I use the csrftoken from cookies and :
http --session=why -h POST https://my.site.io/api-auth/login/ username=user password=pass X-CSRFToken:dT2UuBjp7Xei2iqzmD9A9lNNaTZO8ZHHPh098I8mV27v56E0jePTPgQ0KC3LDmpE -p Hh
This is the out put (With both request and response headers):
POST /api-auth/login/ HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 49
Content-Type: application/json
Cookie: csrftoken=dT2UuBjp7Xei2iqzmD9A9lNNaTZO8ZHHPh098I8mV27v56E0jePTPgQ0KC3LDmpE
Host: my.site.io
User-Agent: HTTPie/2.3.0
csrfmiddlewaretoken: dT2UuBjp7Xei2iqzmD9A9lNNaTZO8ZHHPh098I8mV27v56E0jePTPgQ0KC3LDmpE
HTTP/1.1 403 Forbidden
Connection: keep-alive
Content-Length: 3366
Content-Type: text/html
Date: Thu, 03 Dec 2020 15:33:37 GMT
Referrer-Policy: same-origin
Server: nginx/1.18.0
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
I tried to use X-CSRFToken instead of csrfmiddlewaretoken
I can perform the login through a browser, if a browser is working, i don't see as it can be a problem from the Django Rest Framework configuration. Maybe i'm doing something wrong with httpie
What can it be?
Thanks in advance.
I have a kerberised CDH v5.14 cluster with 3 nodes.I trying to call the HDFS API using python as below
baseurl = "http://<host_name>:50070/webhdfs/v1/prod/?op=LISTSTATUS"
__, krb_context = kerberos.authGSSClientInit("HTTP/<host_name>")
#kerberos.authGSSClientStep(krb_context, "")
negotiate_details = kerberos.authGSSClientResponse(krb_context)
headers = {"Authorization": "Negotiate " + str(negotiate_details)}
r = requests.get(baseurl, headers=headers)
print r.status_code
The below error is returned
GSSException: Defective
token detected (Mechanism level: GSSHeader did not find the right tag)
HTTP ERROR 403
But the same works fine when I run it using curl
curl -i --negotiate -u: http://<host_name>:50070/webhdfs/v1/prod/?op=LISTSTATUS
HTTP/1.1 401 Authentication required Cache-Control:
must-revalidate,no-cache,no-store Date: Wed, 30 May 2018 02:50:04 GMT
Pragma: no-cache Date: Wed, 30 May 2018 02:50:04 GMT Pragma: no-cache
Content-Type: text/html; charset=iso-8859-1 X-FRAME-OPTIONS:
SAMEORIGIN WWW-Authenticate: Negotiate Set-Cookie: hadoop.auth=;
Path=/; HttpOnly Content-Length: 1409
HTTP/1.1 200 OK Cache-Control: no-cache Expires: Wed, 30 May 2018
02:50:04 GMT Date: Wed, 30 May 2018 02:50:04 GMT Pragma: no-cache
Expires: Wed, 30 May 2018 02:50:04 GMT Date: Wed, 30 May 2018 02:50:04
GMT Pragma: no-cache Content-Type: application/json X-FRAME-OPTIONS:
SAMEORIGIN WWW-Authenticate: Negotiate
YGYGCSqGSIb3EgECAgIAb1cwVaADAgEFoQMCAQ+iSTBHoAMCAReiQAQ+6Seu0SSYGmoqN4hdykSQ55ZcP+juBO/jk8/BGjoK5NCmdlBRFPMSbCZXvVjNHLg9iPACGvM8V0jqXTM5UfQ=
Set-Cookie:
hadoop.auth="u=XXXX&p=XXXX#HOSTNAME&t=kerberos&e=1527684604664&s=tVsrEsDMBGV0To8hOPp8mLxyiSo=";
Path=/; HttpOnly Transfer-Encoding: chunked
and it gives the correct response, what am I missing here? Any help is appreciated.
I have a web server that is serving files. Here is a request I make and the answer:
GET / HTTP/1.1
Host: 127.0.0.1:8004
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: djdt=hide; sessionid=1ksbrjhfunsjtywlk2q4p2rl7zrsyvza; messages="Nice and all"
Cache-Control: max-age=0
HTTP/1.0 200 OK
Set-Cookie: csrftoken=Xkg4CnLEahplJPHEJGLrmGvPjebMqyh9; expires=Mon, 09-Feb-2015 21:15:51 GMT; Max-Age=31449600; Path=/, sessionid=qy5guifmpkra78ubkztxxlmk3tu5vr7s; expires=Mon, 24-Feb-2014 21:15:51 GMT; httponly; Max-Age=1209600; Path=/, messages=; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-Age=0; Path=/
Vary: Cookie
Server: gunicorn/18.0
Date: Mon, 10 Feb 2014 21:15:51 GMT
x-frame-options: SAMEORIGIN
Content-Type: text/html; charset=utf-8
Up to that point everything is fine. Things get weird on the very next request:
GET /static/css/bootstrap.css HTTP/1.1
Host: 127.0.0.1:8004
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8004/
Cookie: djdt=hide; sessionid=1ksbrjhfunsjtywlk2q4p2rl7zrsyvza; messages="Nice and all"
If-Modified-Since: Sun, 13 Oct 2013 20:23:36 GMT
Cache-Control: max-age=0
HTTP/1.0 304 NOT MODIFIED
Date: Mon, 10 Feb 2014 21:15:54 GMT
Server: WSGIServer/0.1 Python/2.7.3
Content-Length: 0
Yeah, the browser (Iceweasel) just sent the previous cookies, instead of sending the new one. Actually, it does not take the set-cookie HTTP header into account. That I don't understand. Same behavior on Chromium. On both browsers, nothing appears in the console. When using the developers tools from Iceweasel to the see the request, the previous cookie is parsed in the 'sent cookie', but the received cookie isn't parsed as it should be, such as it is in this (otherwise unrelevant) capture:
You may have notice the Server HTTP response header is different when serving the static file. Indeed, the local Django app serves as a proxy when requesting pages, but serves static content himself. Both contents are on the same domain, same port, so this is supposed to be the same from the browser perspective.
Actually I was coding for downloading the files in HTTP using winsock c++ and to get the details I fired "HEAD" header..
(this is what actually I did)
HEAD /files/ODBC%20Programming%20in%20C%2B%2B.pdf HTTP/1.0
Host: devmentor-unittest.googlecode.com
Response was:
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=feeed8106df5e5f1:TM=1370157208:LM=1370157208:S=10bN4nrXqkcCDN5n; expires=Tue, 02-Jun-2015 07:13:28 GMT; path=/; domain=devmentor-unittest.googlecode.com
X-Content-Type-Options: nosniff
Date: Sun, 02 Jun 2013 07:13:28 GMT
Server: codesite_downloads
Content-Length: 974
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
But if I do:
GET /files/ODBC%20Programming%20in%20C%2B%2B.pdf HTTP/1.0
Host: devmentor-unittest.googlecode.com
The file sucessfully gets downloaded....
After then after I download, again if I fire the HEAD request... it also brings up the following
HTTP/1.0 200 OK
Content-Length: 320381
Content-Type: application/pdf
Content-Disposition: attachment; filename="ODBC Programming in C++.pdf"
Accept-Ranges: bytes
Date: Sun, 02 Jun 2013 05:47:11 GMT
Last-Modified: Sun, 11 Nov 2007 03:17:59 GMT
Expires: Sun, 09 Jun 2013 05:47:11 GMT
Cache-Control: public, max-age=604800
Server: DFE/largefile
//something like this.....
Question: why "HEAD" is returning the false "error not found" at first but the file gets downloaded in using "GET" and after downloading "HEAD" also returns goodies i need...where have i mistaken..
The file I am trying to download here is "http://devmentor-unittest.googlecode.com/files/ODBC%20Programming%20in%20C%2B%2B.pdf" (just for example)
The problem is not on your end. Google Code simply does not implement HEAD correctly. This was reported 5 years ago and is still an open issue:
Issue 660: support HTTP HEAD method for file download urls