What does Allow: GET mean below ?
HTTP/1.1 405 Method Not Allowed
Server: spray-can/1.3.1
Date: Fri, 21 Oct 2016 12:54:34 GMT
Allow: GET
Content-Type: text/plain; charset=UTF-8
Content-Length: 47
If you are using Spring Controller to process the request on the backend,
Make sure to use the annotation #RestController instead of #Controller
Related
I need to test 405 error page, but I have no idea how to create the 405 error.
Is there a way to reproduce 405 error on my site?
HTTP response status code 405 means Method Not Allowed. This status code states that HTTP method was received and recognized by the server, but the server has rejected that particular method for the requested resource.
The easiest way to stimulate the response code 405 is to either
Try to access a non-existing resource/URL
Try to access an existing resource without the proper permission.
Try the following example with an HTTP tool like Postman
The following HTTP request tries to use PUT method on /api/values/ without the right permission
PUT /api/values/1 HTTP/1.1
Content-type: application/json
Host: localhost
Accept: */*
Content-Length: 12
"Some Value"
HTTP Response states code 405
HTTP/1.1 405 Method Not Allowed
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Wed, 15 May 2013 02:38:57 GMT
Content-Length: 72
{"Message":"The requested resource does not support http method 'PUT'."}
I am building a SPA that is backed by a .net webapi using windows authentication hosted in IIS.
When the user hits the home page, it is calling the api via Fetch and getting some data.
Fiddler tells me this i done with Persistant-Auth: true.
When the user clicks a button on the page, it is then posts to the server and creates a record in the database for the user.
Here's the strange thing (Internet Explorer only)...
If the user clicks the button within a minute it will succeed.
Fiddler shows it has used Persistant-Auth: true
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Tue, 14 Nov 2017 16:34:02 GMT
Content-Length: 2
If the user has waited a minute on the homepage it will fail.
Fiddler shows it tried and failed (401) Session-Based-Authentication
HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: NTLM SOMERANDOMTOKEN
Date: Tue, 14 Nov 2017 16:35:30 GMT
Content-Length: 341
Proxy-Support: Session-Based-Authentication
And then it tried again and failed (408)
HTTP/1.1 408 Request body incomplete
Date: Tue, 14 Nov 2017 16:35:30 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache, must-revalidate
Timestamp: 16:35:30.878
Any ideas why this happens and how one would avoid it?
I visit the page http://furryfaust.com/waveform and it redirects to http://furyfaust.com/waveform/ with this initial response.
HTTP/1.1 301 Moved Permanently
Location: /waveform/
Date: Sat, 09 Jul 2016 21:32:56 GMT
Content-Length: 45
Content-Type: text/html; charset=utf-8
I found this out using chrome developer tools. I'm curious where the content-length is determined from since there is no response message body.
The page is served by a web framework called gin (https://github.com/gin-gonic/gin).
There is a content. The developer-tools don't show it for some reason, but using telnet I got the following response:
HTTP/1.1 301 Moved Permanently
Location: /waveform/
Date: Sat, 09 Jul 2016 21:40:38 GMT
Content-Length: 45
Content-Type: text/html; charset=utf-8
Moved Permanently.
Why the dev-tools don't show it? I don't know. Probably because Chrome doesn't even read the content because it'll redirect anyway.
I write a c program to crawl blogs. It works well until it meets this blog: www.ipujia.com. I send the HTTP request:
GET http://www.ipujia.com/ HTTP/1.0
to the website and get the response as below:
HTTP/1.1 301 Moved Permanently
Date: Sun, 27 Feb 2011 13:15:26 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4
Perl/v5.8.8
X-Powered-By: PHP/5.2.14
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Sun, 27 Feb 2011 13:15:27 GMT
Location: http://http/www.ipujia.com/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
This is strange because I cannot get the index page following the Location. Does anyone have any ideas?
The Location field in the response contains a malformed URI.
Location: http://http/www.ipujia.com/ (notice the protocol error)
Should be
Location: http://www.ipujia.com/
Unless you are in control of the server there is little you could do here.
To solve it could you not parse the "Location" response and attempt to extract a valid URI from the it?
I have some static content going through a CDN. I am using IIS6's built in compression (gzip & deflate) for static content and this is working fine when I request it. However, when the CDN makes the initial request for the content, it is not being returned compressed. They therefore don't have compressed content to forward to people requesting it. (Yes this raises the issue of people requesting [the zipped] content from the CDN with a browser that can't handle the compression. - We'll put that to one side for now though)
Here's an example of requesting without the 'Via' header:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
accept-encoding: gzip
And it returns a compressed response:
HTTP/1.1 200 OK
Content-Length: 4357
Content-Type: application/x-javascript
Content-Encoding: gzip
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:52 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:27:50 GMT
However, if I include a 'Via' header in the request (as the CDN does) then the result comes back uncompressed:
Request:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
Via: 1.1 204.160.105.17:80 (Footprint 4.5/FPMCP)
accept-encoding: gzip
Response:
HTTP/1.1 200 OK
Content-Length: 14602
Content-Type: application/x-javascript
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:54 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:29:52 GMT
Yes these demos use 'localhost' in the request. I get the same result using the actual domain name from various machines on various networks though.
Two questions then:
Could this be IIS not applying the compression due to the extra header? and if so what can I do about it?
How can I tell if the proxy is decompressing the content before returning it?
Bonus question 3 - What can I do to investigate this problem further?
I am aware of question 332049, but that has the header in the response, not the request.
I stumbled across your question while researching this myself. I uncovered an article on MSDN and the short answer is that the Via header is used for proxies and proxies typically mess up compression. You either have the option of removing the header or you can change the setting in the IIS metabase (HcNoCompressionForProxies="FALSE"). I had success with both options.