<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Http on Evan Hoffman</title><link>https://evan.wtf/tags/http/</link><description>Recent content in Http on Evan Hoffman</description><generator>Hugo</generator><language>en-US</language><copyright>Evan Hoffman</copyright><lastBuildDate>Fri, 28 Mar 2014 15:17:30 +0000</lastBuildDate><atom:link href="https://evan.wtf/tags/http/index.xml" rel="self" type="application/rss+xml"/><item><title>Rails app redirects to wrong port?</title><link>https://evan.wtf/2014/03/28/rails-app-redirects-to-wrong-port/</link><pubDate>Fri, 28 Mar 2014 15:17:30 +0000</pubDate><guid>https://evan.wtf/2014/03/28/rails-app-redirects-to-wrong-port/</guid><description>&lt;p&gt;Ran into a situation in which a rails application was redirecting to /login to force a user to log in, but the Location header said &amp;ldquo;&lt;a href="http://site.com:8085/login%22"&gt;http://site.com:8085/login"&lt;/a&gt;, because nginx was listening on port 8085 on that server. At first I looked to see if there was something in the application code that was doing this, or maybe some setting I could change to fix it, but came up blank. After some Googling I found the answer right &lt;a href="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect"&gt;in the Nginx docs&lt;/a&gt; (below is my slightly-modified solution that handles https urls as well):&lt;/p&gt;</description></item><item><title>Slow HTTP downloads through Cisco ASA 5500</title><link>https://evan.wtf/2012/02/28/slow-http-downloads-through-cisco-asa-5500/</link><pubDate>Tue, 28 Feb 2012 16:15:20 +0000</pubDate><guid>https://evan.wtf/2012/02/28/slow-http-downloads-through-cisco-asa-5500/</guid><description>&lt;p&gt;Recently we noticed weird behavior downloading files from certain sites. The transfer would start out fast (around 10 MB/s), then after a couple of seconds it would plummet to around 9 KB/s. It didn&amp;rsquo;t happen for every file or every site: downloads from S3 buckets were still particularly fast. But some files that I remember being particularly fast were now showing this weird fast/slow/fast/slow behavior, for example the &lt;a href="http://download.oracle.com/otn-pub/java/jdk/6u25-b06/jdk-6u25-linux-i586-rpm.bin"&gt;Sun JDK&lt;/a&gt; and ISOs from &lt;a href="http://mirrors.rit.edu/centos/6/isos/x86_64/"&gt;rit.edu&lt;/a&gt; that used to saturate our pipe were now getting all cRAzY.&lt;/p&gt;</description></item><item><title>Load balancing in EC2 with Nginx and HAProxy</title><link>https://evan.wtf/2012/01/09/load-balancing-in-ec2-with-nginx-and-haproxy/</link><pubDate>Mon, 09 Jan 2012 17:00:22 +0000</pubDate><guid>https://evan.wtf/2012/01/09/load-balancing-in-ec2-with-nginx-and-haproxy/</guid><description>&lt;p&gt;We wanted to setup a loadbalanced web cluster in AWS for expansion. My first inclination was to use &lt;a href="http://aws.amazon.com/elasticloadbalancing/"&gt;ELB&lt;/a&gt; for this, but I soon learned that ELB doesn&amp;rsquo;t let you allocate a static IP, requiring you to refer to it only by DNS name. This would be OK except for the fact that our current DNS provider, &lt;a href="http://dyn.com/dns/dynect-managed-dns/"&gt;Dyn&lt;/a&gt;, requires IP addresses when using their GSLB (geo-based load balancer) service.&lt;/p&gt;&#10;&lt;p&gt;Rather than let this derail the whole project, I decided to look into the software options available for loadbalancing in EC2. I&amp;rsquo;ve been a fan of hardware load balancers for a while, sort of looking down at software-based solutions without any real rationale, but in this case I really had no choice so I figured I&amp;rsquo;d give it a try.&lt;/p&gt;</description></item></channel></rss>