News for hackers. Stuff that matters.
Re:The Performance Cost of CORS Requests on Single-Page Appl... by makmanalp on Sunday September 02, 2018 @11:29AM (#17897304)
I think this a good interim "solution", but it won't work for everyone. On a larger scale it's rife with issues: e.g. browsers often have a limit to how many downloads they'll do from a single domain in parallel, so stuffing API, assets and pages all into the same domain can limit performance. The other thing is that using DNS to load balance between servers is much more lightweight than using an HTTP proxy / load balancer to direct traffic.
Re:The Performance Cost of CORS Requests on Single-Page Appl... by panarky on Sunday September 02, 2018 @11:48AM (#17897379)
HTTP/2 virtually eliminates the limit on concurrent requests. For example Firefox allows 100 concurrent requests by default with H2.
Re:The Performance Cost of CORS Requests on Single-Page Appl... by londons_explore on Sunday September 02, 2018 @12:33PM (#17897533)
Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website.

They should also use just one domain - DNS lookups are a pretty slow and flaky part of the process of loading a webpage, and downloading loads of HTTPS certificates for all the domains involved isn't great either.

Managing just one domain is also a lot easier - less to monitor, less to maintain, simpler architecture, etc.

The only remaining reason for extra domains is to act as a security boundary - for example when you're running untrusted user javascript.

Re:The Performance Cost of CORS Requests on Single-Page Appl... by chrismorgan on Sunday September 02, 2018 @01:00PM (#17897634)
Your statements are overly definite.

> Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website.

Sure they do. HTTP/2 is not uniformly superior to HTTP/1.1, primarily due to head-of-line blocking; so that on a poor quality network connection, with multiple HTTP/1.1 connections it’s quite possible that one will come through while another takes longer due to packet loss, while on HTTP/2 it’s all on one TCP connection, so that packet loss affects all requests. That’s what QUIC is about fixing. HTTP/2 is also currently incompatible with WebSockets (there’s a draft in progress for resolving that), so HTTP/2 offers no benefit for WebSocket domains or little-to-no benefit for WebSocket-heavy stuff. HTTP/2 also works differently from HTTP/1.1, so that certain moderately obscure combinations of types of long-lived requests can’t be cleanly terminated in HTTP/2 as they can be in HTTP/1.1 (sorry I’m being vague—I can’t recall the details off-hand). And there’s just the usual “existing software that doesn’t support HTTP/2” justification as well.

(Despite the listed criticisms of HTTP/2, I do agree that almost everyone should be using HTTP/2.)

As for QUIC (Google or IETF variant), it’s still experimental, with various unknowns that are being nutted out, and is not suitable for wide deployment by most entities just yet.

> The only remaining reason for extra domains is to act as a security boundary

No, that’s merely one of the best justifications for additional domains. There are other reasons for using other domains, though I would agree with a less strongly worded version of your initial declaration: that they should try, if convenient, to use just one domain.

Re:The Performance Cost of CORS Requests on Single-Page Appl... by kevin_thibedeau on Sunday September 02, 2018 @01:34PM (#17897784)
This isn't a practical solution for embedded web servers where even six concurrent requests can be taxing.
Re:The Performance Cost of CORS Requests on Single-Page Appl... by bdcravens on Sunday September 02, 2018 @12:38PM (#17897547)
Wouldn't it make sense to put the assets that don't need need API access on other domains?
Re:The Performance Cost of CORS Requests on Single-Page Appl... by tootie on Sunday September 02, 2018 @05:04PM (#17898627)
Concurrent connections per domain is much less of an issue now. The max is high enough most apps will never hit it.