Thanks again for your response.
On Sep 28, 2008, at 1:21 PM, Willy Tarreau wrote:
> On Sun, Sep 28, 2008 at 12:59:18PM -0700, John Singleton wrote:
>>> Also, is it possible that the server simply does not accept your
>>> Host: header ?
>> I have no idea :) How could I check/debug this?
> When you telnet into the server port, add "Host: your_domain.com"
> the empty line. If it fails, it means the server is picky about the
>> Should I be rewriting the host headers?
> If the test above fails, yes, you'll have to.
Okay, I added the following line just after the other regular expression:
reqrep ^Host:\ .* Host: s3.amazonaws.com
Which, in my estimation, should rework the host line, no? Tried this but still no luck. I do, however, get a different error. Rather than tell me the bucket <hostname> doesn't exist, it tells me that a hashed key (which looks like an actual bucket hash) so something is happening.
Am I doing that host line correctly?
>>> Do you also have "option httpclose" on the other backend ? It would
>>> be possible
>>> that the static request is always sent as part of a keep-alive
>>> directed to the dynamic backend instead of being switched to the
>>> static one.
>>> In doubt, you should set "option httpclose" in the frontend.
>> It is, in fact. I just tried it on the frontend as well, but no luck.
>> The only notable weirdness is that when I get an error back, the
>> says "no such bucket" and then indicates the hostname as the bucket I
>> was trying to access---which is not the case. So for example, if I
>> to access foo.com/content-cache/web/images/foo.gif, it says "No Such
>> Bucket: foo.com" when in fact I am trying to access the bucket
>> cache. So something is clearly getting mangled.
> It still might be that it refuses requests for foo.com and only
>> I should note that I also tried this exact same setup with another
>> service, CacheFly.net (very fast, global, pay as you go CDN) and it
>> doesn't work either. In the CacheFly setup, I structured the
>> directories so that I didn't need to rewrite the URLs---so clearly
>> rewriting the URL isn't the problem here, but rather some general
>> problem that prohibits it from working with CDN setups. Doing it with
>> a web server on the backend (apache, lighttpd) works flawlessly.
> I would say it's heading towards a Host: issue :-/
> I hope it's just that, in which case it'll be an easy config fix.
Received on 2008/09/29 19:52
This archive was generated by hypermail 2.2.0 : 2008/09/29 20:01 CEST