40 ms·
Does anyone have insight on why they're making this change? All they say in this post is "In our effort to continuously improve customer experience". From my po
by TheLoneTechNerd 7y ago
Does anyone have insight on why they're making this change? All they say in this post is "In our effort to continuously improve customer experience". From my point of view as a customer, I don't really see an experiential difference between a subdomain style and a path style - one's a ".", the other's a "/" - but I imagine there's a good reason for the change.
- ynniv 7y agoI have no visibility into Amazon, but using subdomains let you shard across multiple IP addresses.
- zmmmmm 7y agoThe only obvious thing that occurs to me is that bringing the bucket into the domain name puts it under the same-origin policy in the browser security model. Perhaps there are a significant number of people hosting their buckets and compromising security this way? Not something I have heard of but it seems possible. Makes me wonder if they are specifically not mentioning it because this is the reason and they know there are vulnerable applications in the wild and they don't want to draw attention to it?
- TheLoneTechNerd 7y agoRemoving my comments because I can't seem to delete them...
- tedunangst 7y agoDoes it bother you the domain is amazon.com and not com.amazon?
- yjftsjthsd-h 7y agoI can't read what you're replying to, but it absolutely bothers me. The current scheme has this completely random double reversal in the middle of the URL; it would have been so trivial to just make it actually big-endian, but instead we have this big-little-big endian nonsense. Far too late to change it now, but it is ugly and annoying.
- chtitux 7y agoProbably because they want to improve the response time with a more precise DNS answer. With s3.amazonaws.com, they need to have a proxy near you that download the content from the real region. With yourbucket.s3.amazonaws.com, they can give an IP of an edge in the same region as your bucket.
- iampims 7y agoIt’s a known trick for spammers to leverage the amazon domain to rank higher in search rankings.
- bayareanative 7y agoVirtual and path style share the same domain suffix. It's also *.amazonaws.com, not amazon.com.
- willglynn 7y agoPublic suffix list: https://publicsuffix.org https://publicsuffix.org s3.amazonaws.com subdomains are as distinct from each other as co.uk subdomains.
- driverdan 7y agoThat's a search engine problem, not a hosting problem.
- BillinghamJ 7y agoThree reasons - First to allow them to shard more effectively. With different subdomains, they can route requests to various different servers with DNS. Second, it allows them to route you directly to the correct region the bucket lives in, rather than having to accept you in any region and re-route. Third, to ensure proper separation between websites by making sure their origins are separate. This is less AWS's direct concern and more of a best practice, but doesn't hurt. I'd say #2 is probably the key reason and perhaps #1 to a lesser extent. Actively costs them money to have to proxy the traffic along.
- deleted 7y ago[deleted]
- cobookman 7y agoWith Software defined networking you don't need the subdomain to do that.
- wbl 7y agoHuh? If the DNS doesnt see the bucket name how can it hand back the right IP of where the bucket lives?
- tedunangst 7y agoHow does that work? My browser is going to send all requests to the same domain to the same place.
- cobookman 7y agoAnycast ip. You have a sole ip address. All traffix routed to nearest PoP. The PoP makes the call on where and how to route the request. Lookup google front end (GFE) whitepaper. Or thd google cloud global load balancer That front end server that lives in the PoP can also inspect the http packets for layer 7 load balancing. https://cloud.google.com/load-balancing/docs/load-balancing-overview https://cloud.google.com/load-balancing/docs/load-balancing-...
- deleted 7y ago[deleted]
- dillondoyle 7y agoI would guess cookies and other domain scoped spam/masking 'tricks'? I've never tried but perhaps getting a webpush auth on that shared domain could cause problems
- Gasparila 7y agoOne big reason to me: cookie security Currently all buckets share a domain and therefore share cookies. I've seen attacks (search for cookie bomb + fallback manifest) that leverage shared cookies to allow an attacker to exfiltrate data from other buckets
- notfed 7y agoCookies support URL path restrictions.
- nyuszika7h 7y agoThat doesn't prevent unauthorized reading of the cookies. The only way to properly prevent it is using a different domain/subdomain. https://developer.mozilla.org/en-US/docs/Web/API/document/cookie#Security https://developer.mozilla.org/en-US/docs/Web/API/document/co...