From a XHR feature set perspective the following two statements are a little contradictory as
responseURL appears to only have been in the specification since February. I know that there appears to be issues with the redirection however from an API perspective adding new features that are optionally off should never be an issue.
However with that being said; I wasn't quite aware of the far reaching goals of fetch however I guess the following covers it:
@annevk perhaps you would be able to clear up some of the CORS issues; I did quite a bit of digging before writing the above article back in November however its not always clear the motives and issues causes whilst trying to implement features into the spec - hence this discourse I guess.
Some of my reasons for wanting full granularity of the request redirection and also control are:
- Headers are currently not visible for redirected requests
- Visibility of the redirected hops through for debug and also security reasons
- Josh has outlined CSP for a security perspective to prevent internal redirecting however for a per request granularity prevention this would need to be done at code time (Lets say for example an external agency owned a certain directory, subdomain or script on the same server)
- A way in which the browser can verify the server behaved exactly as expected.
- As mentioned for single applications; it is useful to behave in the same way for different content type responses from the server HTML/XML/JSON in the same manner; from a client perspective having a full trace of where they have landed is key to displaying the correct template (Assuming a design pattern where front and back end match in URL's and behaviour).
Thank you both for your time.