Comments
-
Greg Hurrell
Ok, I've revisited this.
The logic is as follows, in a mailer we don't actually have a "request" object so we can't inspect that to decide which protocol, host and port to use in our links.
In fact, even if we could inspect it, we wouldn't want to, because we want to ensure that all outgoing links use the authoritative, "canonical" URL, which in our case means protocol HTTPS, host wincent.dev, and port 443. (ie. if we made a mistake in our firewall config and someone somehow managed to connect directly on port 80, or via another port Mongrel was listening on, we wouldn't want the generated URL to have some odd port number in it.)
Therefore, in our mailers we want to set up host and port values based on hard-coded defaults read from a YAML file.
This is basically the way it currently works under Rails 2.
We only set explicit port number if it is a non-standard port (eg. not 80 or 443), otherwise we needlessly get the port number in URLs (ie. https://wincent.dev:443/foo when https://wincent.dev/foo would suffice, or https://wincent.dev:80/bar when https://wincent.dev/bar would suffice). So this in practice means that we only set up the host value.
Note that under Rails 2 all of our routes have an explicit
protocol
set on them, which means that things likecomment_url(comment)
in a mailer will generate an HTTPS URL by default.Under Rails 3 things are different.
We've dropped the explicit protocol from our routes in order to make local testing easier, which means that route helpers no longer produce HTTPS URLs by default when we call things like
comment_url
. Those are now dependent on the request. ie. on an HTTPS page, the URL will be HTTPS, and on an HTTP page it will be HTTP.This in turn means that when used in mailers when no request is available, links will always be HTTP links unless we pass in an explicit port number of 443. Unfortunately this means that our links will always have a redundant port number in them (ie. https://wincent.dev:443/foo instead of https://wincent.dev/foo). Luckily, we can avoid this by passing in
:protocol => 'https'
. -
Greg Hurrell
Ok, I believe this is handled now. Marking as closed.
-
Greg Hurrell
Status changed:
- From: new
- To: closed
Add a comment
Comments are now closed for this issue.