You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we internally resolve files and return responses as though the user loaded the resolved file.
This should optionally be disabled and 302 responses should be sent.
The redirect flag is what handles this in regular fetch.
So if a user sets redirect to manual, we would resolve the file, and return a 302 redirect so that the protocol handler or user can resolve themselves if they so choose.
We should also consider whether we should return a 302 redirect when a request gets made for a DNS address or a named drive. I think DNS doesn't make as much sense since you'd want to preserve the origin, but named drives could make sense so that users are less confused as to how to get the actual URL of the drive they created.
The text was updated successfully, but these errors were encountered:
Right now we internally resolve files and return responses as though the user loaded the resolved file.
This should optionally be disabled and 302 responses should be sent.
The redirect flag is what handles this in regular fetch.
So if a user sets
redirect
tomanual
, we would resolve the file, and return a 302 redirect so that the protocol handler or user can resolve themselves if they so choose.We should also consider whether we should return a 302 redirect when a request gets made for a DNS address or a named drive. I think DNS doesn't make as much sense since you'd want to preserve the origin, but named drives could make sense so that users are less confused as to how to get the actual URL of the drive they created.
The text was updated successfully, but these errors were encountered: