I 'think' I've just got my DNS setup they way you described. Waiting for it to propogate....
Will check back in a few hours. -Jim On Tue, Feb 12, 2013 at 1:48 PM, Giles Thomas <[email protected]>wrote: > Your DNS providers aren't completely in the wrong. The problem as I > understand it is that the DNS standard itself doesn't support CNAMEs for > "naked" domains, like foo.com, if you have any other data associated with > them -- like mail records. See < > http://superuser.com/questions/264913/cant-set-example-com-as-a-cname-record>. > This is something that it would be great if the standards bodies fixed, but > standards move slowly and there may be underlying problems that I just > don't understand that would make it hard to change. > > So the question is, why use CNAMEs instead of A records? If you're using > a hosting provider, it adds a level of indirection where your they can > change stuff to load-balance your site without asking you to set up your > own complex DNS stuff (round-robin, etc) or constantly change the IP you're > pointing to. This is useful not just for smaller sites, some of the big > ones do this -- "dig www.reddit.com" for a nice example, it looks like > they're using Akamai. > > Anyway, I think the real underlying requirement is that lots of people > want to have their site visible at both foo.com and www.foo.com. The > answer we've chosen for the PythonAnywhere website itself is to have the > "official site" at www.pythonanywhere.com, and then to ask our DNS > provider (Joker.com) to do an HTTP-level redirect, so that > http://pythonanywhere.com/something gets redirected over to > http://www.pythonanywhere.com/something. I do that on my personal blog > too -- see http://gilesthomas.com/. > > This has two advantages: firstly, by making the "www" domain the official > one, we can use a CNAME and load-balance ourselves like we do our > customers. Secondly, instead of having two identical sites at slightly > different hostnames, we have one canonical one at one domain. This means > that all incoming links to our site go to the canonical version, which > means that the Google PageRank effect of the incoming links isn't spread > across two "different" domains, so we get a higher overall PageRank. > (There's also possibly an advantage in that Google apparently downrank > sites that appear to just be copies of other sites, and by only having one > official site then you lower the risk of that happening.) > > Now, given the weirdness you saw earlier with http_referrer and http_host > being wrong, it's actually quite possible that your current DNS host > support an HTTP-level redirect like the one we have. So if you set that up > so that yourdomain.com does an HTTP redirect to www.yourdomain.com, and > then www.yourdomain.com has a CNAME to yourusername.pythonanywhere.com, > you should be set! > > I hope that wasn't too rambling and incoherent... > > > All the best, > > Giles > > > > > > On 12 February 2013 19:03, Jim Steil <[email protected]> wrote: > >> Yes, I don't believe it is a pythonanywhere problem. I'm using mydomain >> for DNS hosting. They are now telling me that I cannot setup a cname for >> my root domain if I'm using their mailservers and have the mx records point >> to them. That sounds like a bunch of crap to me, but that is what their >> support is telling me. >> >> The problem I was having earlier was when I had the DNS setup to point >> the url to myaccount.pythonanywhere.com. Why were sending the traffic, >> but the referer was set to urlOfMyApp.com and http_host was set to >> myaccount.pythonanywhere.com. So, I definitely think it is a DNS host >> problem but they are telling me that what I want to do is not possible, >> with them or any host. I'm in no position to argue because I know little >> or nothing of DNS. >> >> -Jim >> >> >> On Tue, Feb 12, 2013 at 12:33 PM, Giles Thomas <[email protected]>wrote: >> >>> Hi there, >>> >>> PythonAnywhere developer here. I assume that the request environment >>> where Jim S was seeing the incorrect http_host is the underlying WSGI >>> environment -- is that correct? If so, that's a weird result. We >>> definitely don't do anything strange and hacky with those headers; I just >>> ran a test app to confirm and it was set to the correct domain -- that is, >>> I saw the correct http_host, and the http_referer was unset. >>> >>> Jim, perhaps you could point me at the app that had that error? Is >>> there any chance that you'd set up a non-CNAME redirect at your DNS >>> provider? I know that Joker (our one) offers not just CNAMEs but >>> "Web-redirects", which just does an HTTP redirect to the name you provide. >>> Perhaps your provider confuses the two in their interface? >>> >>> Just for clarity: the link through to the username.pythonanywhere.comdomain >>> works purely at the DNS level. We need to be able to move web apps >>> from IP address to IP address for load balancing, so we ask our customers >>> to set up their domain with a CNAME to username.pythonanywhere.com with >>> their DNS provider. But that's just a DNS thing; by the time a request >>> from a browser gets to our servers, it's just to a specific IP address, >>> with the appropriate Host: header in the HTTP request. >>> >>> There should definitely be no weird redirects going on; requests are >>> routed to the appropriate WSGI app based entirely on the hostname provided >>> in the HTTP request, and while that routing knows about which user's >>> sandbox the request should be routed to, it knows nothing about the >>> username.pythonanywhere.com domain. >>> >>> >>> All the best, >>> >>> Giles >>> >>> >>> >>> >>> >>> On Tuesday, February 12, 2013 4:07:19 PM UTC, Jim S wrote: >>>> >>>> Yes, might be a show-stopper for me and others trying to use >>>> pythonanywhere. I was thinking there were others on the list using >>>> pythonanywhere successfully with web2py. My problem is I know little about >>>> DNS and routing. My DNS is hosted by mydomain.com. There is also a >>>> good chance that I've got something screwed up there too... >>>> >>>> -Jim >>>> >>>> On Tuesday, February 12, 2013 9:58:11 AM UTC-6, Jonathan Lundell wrote: >>>>> >>>>> On 12 Feb 2013, at 7:48 AM, Jim S <[email protected]> wrote: >>>>> >>>>> Looking at request.env I'm seeing the following: >>>>> >>>>> http_host = >>>>> myaccountname.pythonanywhere.**com<http://myaccountname.pythonanywhere.com> >>>>> http_referer = http://www.myappurl.com >>>>> >>>>> I'm routing in my routes.py based on www.myappurl.com but it never >>>>> goes there. It is always going to >>>>> myaccountname.pythonanywhere.**com<http://myaccountname.pythonanywhere.com> >>>>> . >>>>> >>>>> >>>>> Interesting. That seems like a real hack on the part of Python >>>>> Anywhere, and not just because of this problem, but also because you have >>>>> no idea what the real referrer is. Lots of analytics tools depend on that. >>>>> >>>>> >>>>> -Jim >>>>> >>>>> On Tuesday, February 12, 2013 9:25:27 AM UTC-6, Jim S wrote: >>>>>> >>>>>> So you mean to just look at it through a regular view, not in the >>>>>> routes.py. Got it. Wasn't thinking straight. >>>>>> >>>>>> -Jim >>>>>> >>>>>> On Monday, February 11, 2013 11:13:23 PM UTC-6, Jonathan Lundell >>>>>> wrote: >>>>>>> >>>>>>> On 11 Feb 2013, at 7:48 PM, Jim Steil <[email protected]> wrote: >>>>>>> >>>>>>> Sorry for being slow at this, route configuration is certainly not a >>>>>>> forte of mine. Is there something special I need to do to turn on >>>>>>> logging? >>>>>>> How would I examine request.env? I'm running all of this from >>>>>>> pythonanywhere and don't really know where to find these things. >>>>>>> >>>>>>> >>>>>>> >>>>>>> =BEAUTIFY(request) or =BEAUTIFY(request.env) should do the trick. >>>>>>> >>>>>>> Logging depends on your deployment, but it's worth figuring out. >>>>>>> Look at logging.example.conf. You can set the loglevel of routing in >>>>>>> routes.py. >>>>>>> >>>>>>> It's really too bad that logging is such a pain to get configured, >>>>>>> because it's really valuable. >>>>>>> >>>>>>> >>>>>>> -Jim >>>>>>> >>>>>>> On Mon, Feb 11, 2013 at 9:06 PM, Jonathan Lundell <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> On 11 Feb 2013, at 7:01 PM, Jim S <[email protected]> wrote: >>>>>>>> >>>>>>>> Jonathan >>>>>>>> >>>>>>>> I am currently using that as my base for getting this working. >>>>>>>> Here is what I have so far: >>>>>>>> >>>>>>>> routers = dict( >>>>>>>> # base router >>>>>>>> BASE=dict(domains = {"www.website1.com":"mustangs"**, >>>>>>>> "www.website2.com":"icysa", })) >>>>>>>> >>>>>>>> But, anytime I to either URL, I get the web2py welcome app. >>>>>>>> >>>>>>>> Also, I've saved the file as routes.py. >>>>>>>> >>>>>>>> >>>>>>>> And restarted, right? >>>>>>>> >>>>>>>> Try turning on logging for routes and see what you get. You might >>>>>>>> also examine request.env, and make sure that the target domain is >>>>>>>> showing >>>>>>>> up properly. >>>>>>>> >>>>>>>> >>>>>>>> -Jim >>>>>>>> >>>>>>>> On Monday, February 11, 2013 6:32:41 PM UTC-6, Jonathan Lundell >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 11 Feb 2013, at 3:36 PM, Jim S <[email protected]> wrote: >>>>>>>>> >>>>>>>>> I'm trying to route traffic that comes in on a specific URL to a >>>>>>>>> specifc app. >>>>>>>>> >>>>>>>>> Example: >>>>>>>>> >>>>>>>>> www.host1.com should route to the welcome app >>>>>>>>> >>>>>>>>> www.host2.com should route to mySpecific app >>>>>>>>> >>>>>>>>> I realize this is probably trivial, but I'm really struggling with >>>>>>>>> it. Hoping to do it with routes.py and not through wsgi stuff. >>>>>>>>> Please >>>>>>>>> feel free to set me straight if that is not advisable. >>>>>>>>> >>>>>>>>> >>>>>>>>> Look at the domain-routing provision in the parametric router. >>>>>>>>> Documentation in the book, and in router.example.py. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "web2py-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Giles Thomas > [email protected] > http://www.gilesthomas.com/ > http://learningwebgl.com/ > http://pythonanywhere.com/ > > > <http://learningwebgl.com/> > > -- > > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
