Is there a way to raise a 505 exception with ruby on rails in development?
I would like to testdrive my custom 505 exceptions but found no documentation on how to raise a 505 anywhere.
i am a little confused here. are you talking about a 505 status codes? or are you talking about raising exceptions?
i don't think that there is a 505 exception, so i assume you are talking about HTTP status code version not supported (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
it could be as simple as this:
def index
render nothing: true, status: 505
end
if you call an action like that you will get something like this as a response:
curl -I http://hamburg.onruby.dev:5000/
HTTP/1.1 505 HTTP Version not supported
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-UA-Compatible: chrome=1
Content-Type: text/html; charset=utf-8
X-Meta-Request-Version: 0.2.8
Cache-Control: no-cache
Set-Cookie: locale=de; domain=onruby.dev; path=/; expires=Sat, 11 Oct 2014 07:45:52 -0000
X-Request-Id: b8232480-5585-4e99-bc4c-44019e41db6a
X-Runtime: 0.010615
Connection: close
Server: thin 1.5.1 codename Straight Razor
Related
Most of the documentation talks about adding config.force_ssl = true which provides HSTS to Rails application. Well, how can I make sure its working as expected? How can I test HSTS header is added for every request? Any help is much appreciated.
Use curl -I https://your_website.domain or browser developer tools to view response headers. You're interested in the Strict-Transport-Security header:
curl -I https://www.ssllabs.com/
HTTP/2 200
date: Fri, 23 Apr 2021 15:25:17 GMT
server: Apache
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=31536000 <-- this one
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
x-frame-options: DENY
content-type: text/html;charset=ISO-8859-1
content-language: en-US
content-length: 6587
set-cookie: ...
content-security-policy: ...
I'm quite new to caching so I've been trying some different ways of caching my website. I've settled on HTTP caching now, because it's the most appropriate with sporadic updates and lots of users perusing the same pages over and over.
I'm struggling to get it working however. The site shows different content based on whether you're logged in or not, so I have to invalidate cache based on current_user as well as the latest update on the collection of models.
If I look in chrome inspect the ETag and the modified_since are the same, but the server returns a 200 instead of a 304. My code works in development environment, so I'm lost in how to troubleshoot it. Also a different page that only invalidates based on the collection of models (similar on latest update), does work as expected.
Code from the controller:
def index
...#some code
# HTTTP caching:
last_mod = #scraps.order("updated_at").last.updated_at
user = current_user ? current_user.id : 0
fresh_when etag: user.to_s, last_modified: last_mod, public: false
end
Output from chrome inspect
Response Headers:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Status: 200 OK
Last-Modified: Sun, 23 Jul 2017 20:40:53 GMT
Cache-Control: max-age=0, private, must-revalidate
ETag: W/"6e92592bdb6c3cf610020e2b076e64b4"
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Runtime: 3.187090
X-Request-Id: c698c0c6-8a0d-44ba-8ca9-3f162b766478
Date: Mon, 24 Jul 2017 14:49:38 GMT
Set-Cookie: ... [edited out]; path=/; HttpOnly
X-Powered-By: Phusion Passenger 5.0.30
Server: nginx/1.10.1 + Phusion Passenger 5.0.30
Content-Encoding: gzip
Request Headers:
GET /scraps?page=3&price_max=100&price_min=0&producer=silk+scraps HTTP/1.1
Host: www.picture-scraps.com
Connection: keep-alive
Accept: text/html, application/xhtml+xml, application/xml
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
X-XHR-Referer: https://www.picture-scraps.com/scraps?page=4&price_max=100&price_min=0&producer=silk+scraps
Referer: https://www.picture-scraps.com/scraps?page=4&price_max=100&price_min=0&producer=silk+scraps
Accept-Encoding: gzip, deflate, br
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,af;q=0.2
Cookie: ... [edited out]
If-None-Match: W/"6e92592bdb6c3cf610020e2b076e64b4"
If-Modified-Since: Sun, 23 Jul 2017 20:40:53 GMT
I can imagine some additional information is needed, so please request and I'll add to the question.
Figured it out today. This post provides the answer. I saw the server used weak etags while in the dev environment strong etags were used. The latter is as expected as weak etags were only introduced from rails 5 forward.
If you use Nginx with rails 4 you might experience the same problem. Installing rails_weak_etags gem solved it for me.
I've got a strange issue and I'm running out of ideas. In my Rails(4.2)-App I'm using the fresh_when-Method to invalidate client caches for my blog pages:
def show
#post = Post.find(params[:id])
fresh_when #post
end
With curl everything works out fine, sending the matching Etag gives me a 304 response:
celmare$ curl -i -H 'If-None-Match: "3b4dd96aac692c03ce623db459c9cef2"' https://grosse.io/blog
Response:
HTTP/1.1 304 Not Modified
Connection: keep-alive
Status: 304 Not Modified
Last-Modified: Sun, 04 Oct 2015 10:41:08 GMT
Cache-Control: max-age=0, private, must-revalidate
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 1; mode=block
X-Request-Id: 68a0ecd2-3fac-4004-ac1e-fd6d14780f61
ETag: "3b4dd96aac692c03ce623db459c9cef2"
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.006207
X-Content-Type-Options: nosniff
Date: Thu, 29 Oct 2015 13:17:02 GMT
X-Powered-By: Phusion Passenger 5.0.15
Server: nginx/1.8.0 + Phusion Passenger 5.0.15
When I open the page in the browser (e.g. Chrome Version 47.0.2526.35 beta (64-bit)) I always get 200 although the Etag still matches:
Request headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Cookie:_gat=1; _syscfg_net_v2_session=eGFlYk83Z0kwUE9IYmtUVHg1Z1ppbHF2eFBrUitiTDBsRG1Kbml2bW8vQVZ6YW4xM0ZuRTNOS0w2VmVLM1ZaN0czZno3N0Y2MWpiUWNjQUV0YkVlaXhCZUJyZlJWWEVIZVpPclFaaHZxdFNncjNBVVg3MFR2SE0yWDRUaklsSlRMbmw4OVQrQmlDRHBIbmRSMS9VVml3PT0tLTYvUGdURTRaRjNXSU9WOTdOY1F3OEE9PQ%3D%3D--3bafbda7d522c61cd9fd04898c2c6a4bac06131b; _ga=GA1.2.235147781.1445350582
Host:grosse.io
If-Modified-Since:Sun, 04 Oct 2015 10:41:08 GMT
If-None-Match:W/"3b4dd96aac692c03ce623db459c9cef2"
Referer:https://grosse.io/blog
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.35 Safari/537.36
Response headers:
Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Thu, 29 Oct 2015 13:16:48 GMT
ETag:W/"3b4dd96aac692c03ce623db459c9cef2"
Last-Modified:Sun, 04 Oct 2015 10:41:08 GMT
Server:nginx/1.8.0 + Phusion Passenger 5.0.15
Set-Cookie:_syscfg_net_v2_session=MUtjWlQyY1ZFZnF2TzlvTDJkdnpmMDhqVmhoVld5YkJDdHl5NUtIdXJTY1VZQ1AzV1NVMjF1alFDSE9NKzliOGhzcmc4S3FLajRmNGFZUjltQzdPNDg4SW51aUxGU2xDd0FxVi82UFZneE5YU1FnTjJVSFhpL3RCQkNYdjlFVTlyZVRRU0ZPdG83UFNVbjVyckJmZ0R3PT0tLXh4Zzg0cjhBSTZKbVpkayttanpwUFE9PQ%3D%3D--dc404af2428a17085bea4b40a3f4f0fc6ef01e50; path=/; secure; HttpOnly
Status:200 OK
Strict-Transport-Security:max-age=31536000
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Powered-By:Phusion Passenger 5.0.15
X-Request-Id:0633095f-b95d-4339-8e62-8b15683c2d8c
X-Runtime:0.034172
X-XSS-Protection:1; mode=block
And on top: In my local env it's working with the same browser. I can hardly imagine that it is a NGINX thing because the everything is configured very defaulty. Could it be something with HTTPS?
Any ideas? Thanks in advance.
Ok, I found the cause. It's a problem with NGINXs gzip compression in combination with weak "W/" Etags. Will try upgrading NGINX or using a Patch.
Adding etag on; after gzip on; in nginx.conf fixed the problem from 1.7.4 and newer.
i use nginx 1.8.0 under centOS 6.7 which serving Ruby On Rails 4.2.3 application.
The Problem:
I need to enable iframe options for all domains so tried this:
X-Frame-Options: *
then when i check headers i see it twice 1 time with SAMEORIGIN and one time with *, here is the response:
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Sun, 01 Nov 2015 15:48:32 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Status: 200 OK
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
ETag: W/"d14b3de05fb18ebe4a94774c8f209e7f"
Cache-Control: max-age=0, private, must-revalidate
Set-Cookie: guess_locale=en; path=/; secure
Set-Cookie: _admin_numgames_com_session=Y3N0QjR2NXY0VFlZMlVnMHJLZC9WbUVraldZYjhpeHo0UG41akpaZE1rb0tQWS9YeGpkcklTRmViUU5aVmJpUElCcWpMaFJWQmpIWHRSazI4TE9QdTgvQ2VVRGYrSW9VcjA4eWVCMVlsUHJRejR1WmNoQWZoL2hGeVA1ZHp5YWxPdFZ4S25ydEtTamVnbFlZMEhJRDdXalQ2MU93T24vWnR6b28wM0NvYS82Nm1XMGV2Njh4djIzR1RNb2w3WTVHUDM3cVl3NnVrQnJ1WTMyU3I4dVBjY3RORWRQSlk2VmhNVnRVelZRbHRVWT0tLU9DYVBIZUxoUXlLN2VmZ01VNEhab3c9PQ%3D%3D--fa2a9d6817b5464b82a2babd784ed098f2526eeb; path=/; secure; HttpOnly
X-Request-Id: 4762503a-a9a8-41ce-b1a7-26269b7e9184
X-Runtime: 0.963198
X-Frame-Options: *
there is only 1 time declare this option so why i see it twice? and how do i remove this option so any one will be able to use my domain with iFrame?
OK so i found the solution and Rails was the problem he sent the header, just needed to add into production.rb file:
config.action_dispatch.default_headers = {
'X-Frame-Options' => 'ALLOWALL'
}
I am working on a project which requires a client to make an api call to
my
rails application and it to return XML without any http header info.
its currently returning:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Content-Type: application/xml; charset=
X-Ua-Compatible: IE=Edge
X-Request-Id: c5602cd7eb23ca8137bef8bb1f0a4f8a
X-Runtime: 0.027900
Server: WEBrick/1.3.1 (Ruby/1.9.3/2013-11-22)
Date: Wed, 18 Jun 2014 05:27:48 GMT
Content-Length: 529
Connection: Keep-Alive
Set-Cookie: _session_id=a8039d615674feec206e6c55a7a7afc8; path=/;
HttpOnly
<?xml version="1.0" encoding="UTF-8"?>
<cXML>
<Response>
<Status code="200" text="OK"/>
<StartPage>
<URL>http://localhost:3000/foobar/BAh7DDoNYmFza2V0aWRJI...
</StartPage>
</Response>
</cXML>
Can anyone help to remove all the http headers within the controller or any
config? which is below section.
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Content-Type: application/xml; charset=
X-Ua-Compatible: IE=Edge
X-Request-Id: c5602cd7eb23ca8137bef8bb1f0a4f8a
X-Runtime: 0.027900
Server: WEBrick/1.3.1 (Ruby/1.9.3/2013-11-22)
Date: Wed, 18 Jun 2014 05:27:48 GMT
Content-Length: 529
Connection: Keep-Alive
Set-Cookie: _session_id=a8039d615674feec206e6c55a7a7afc8; path=/;
HttpOnly
I am using nginx at the moment.
I have some says that this is kind of a nonsense request, since HTTP servers by
definition uses header to talk to one another. But I have also been informed that W3 think otherwise.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4
I have also googled around for hours attempting other solutions changing my rails controller without any success. Is the last resort possibly changing config in Nginx and wouldn't that effect the whole rails application and not just the api calls or is there a way to single out one call?
Thanks in advance.
T
This is a nonsense request, yeah. You can use the HttpHeadersMore module to remove most of the response headers. Something like this should do it:
location /your/api/path {
more_clear_headers '*';
}
However, you can't remove the Connections header without patching nginx. And even if you could, you can't remove the first line of the response ("HTTP/1.1 200 OK", in this case). Without that line, it isn't an HTTP response. You're going to have a hard time convincing an HTTP server to send non-HTTP responses.
To get what you're describing, I think you'll need a custom server that communicates over bare TCP sockets. This tutorial might help you out. Or maybe you could implement that part of your app in node.js (or another tool)?