`301` means "Moved Permanently", so browser caches this redirect, it is used when changing server URL.
`302` means "Found", it is used generally (e.g. redirect top page after
login).
Each of `301`, `302`, `303` and `307` means redict, but they are
different. We could choice those status in case.
Removed `env.redirect` in-favor of `redirect` in-order to make Kemal's
API look more like Sinatra.
Thanks @sdogruyol and @f for introducing me to macros :-).
Binding HTTP::Server to 0.0.0.0
First I tried implementing this solution in such a way that it
explicitly clears body and set `Content-Length` header to body's size.
But for some reason, if I call the URL from cURL then `Content-Length`
header was blank which defeats the very purpose of `HEAD` requests.
I then later anticipated that since `HEAD` would be by-default
implemented by `HTTP::Server` module, there is no need to explicit
clears body and setting `Content-Length` but the way we have written
our previous specs were returning body as well. We could have used some
TestServer kind of thing but if we go to that route we explicitly need
to test non-existent route which I thought would create some
inconsistency among specs.
Crystal has clearly written specs for HEAD requests to make sure body
is not read for them. See
https://github.com/manastech/crystal/commit/acd0b6afb5af438a30529c36b11b
e7954336f23f. I decided to write simple specs which are easy to
maintain in long-run.
We are adding identical HEAD route for every GET route which will make
HEAD requests available for all defined GET requests.
https://github.com/sdogruyol/kemal/issues/19
Added comment for code line which is adding HEAD routes for defined GET routes.
Following are the changes made in this commit:
- Added support for magic param `_method` just like Rails, Sinatra
etc.. Browsers which don't support `PUT`, `PATCH` and `DELETE` methods
can simulate them by sending `method` param in request body.
- The default Content-Type to parse request body submitted via forms
etc. is `application/x-www-form-urlencoded`. But if we send Ajax
request in Chrome ($.post) then by-default Content-Type is set to
`application/x-www-form-urlencoded; charset utf-8` which was not
getting matched. I changed the code from `==` to match against a
regular expression using `=~`.
- Print name and color of overridden HTTP method via Logger instead of
printing name and color or request's incoming HTTP method.
Making necessary changes as pointed by @sdogruyol
- Changed method name from`is_override_method_valid?` to
`override_method_valid?`.
- Refactored `if` condition in `override_method_valid?`.
