Re: [whatwg/fetch] Why does Fetch specify a max redirect count of 20? (#576)

@annevk Our network stack takes a different approach than Firefox, and is more similar to the CFNetwork+WebKit split or WinHTTP+Edge split - two separate layers. HSTS is implemented by our //net layer, and is thus opaque in handling and processing to the Chrome (and, from the POV of Chrome, Fetch) layer. This is where the opposition to internal/external comes from - it is, from an API perspective, exposing an implementation detail of our networking stack, and one whose ontology differs based on different consumers (e.g. whether a given redirect is injected from a higher layer - e.g. U-I-R or extensions - or comes from a lower layer - like HSTS - can result in different categorizations based on different //net consumers' needs). This is further amplified by future steps Chrome is taking to move its networking into a dedicated sandboxed process (and potentially consumed by non-Chrome applications)

In evaluating whether or not to make this split (which affects a variety of features that have redirect-specific behaviours, such as our omnibox search logic), we've consistently decided that treating them holistically is more desirable and more understandable for the various //net consumers. Thus, we've allowed a small CORS layering violation to be introduced into //net, rather than force all //net consumers to be aware of the ontology (or to support extending the ontology, as necessary for some of these consumers). That logic is in https://cs.chromium.org/chromium/src/net/url_request/url_request_redirect_job.cc?rcl=49b1594550778be788e86953fe6d17401e96b5f8&l=100 (while that code is shared by some, but not all, of internally generated redirects), as detailed in https://chromium.googlesource.com/chromium/src/+/4e0be1f338c3bb9bb3c347cdb4c5e3b7944c5c67

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/576#issuecomment-322244707