Hi, I'm investigating OAK-8013 and looking for more opinions on what to do. The problem is not as simple to solve as it seems due to inconsistent behavior in Azure, which appears to be a bug in their SDK, and I'm not sure how to handle this in the meantime.
The basic issue for OAK-8013 relates to how we specify the value for the Content-Disposition header to be set on a direct download. When requesting a direct binary download URI, both S3 and Azure allow us to specify the value that the provider should put in the Content-Disposition header when the URI is requested. Currently, Oak does not properly encode the "filename*" portion of this value, which can lead to parsing errors for clients that parse the response. See OAK-8013 for details. Properly encoding the "filename*" part works great in S3, but not in Azure due to some odd behaviors in how they sign the URI and how (and when) they encode the URI parameters. See OAK-8013 for details; ultimately this appears to be a bug in the Azure SDK, but it is probably too early to state this definitively. I think the proper way to solve this problem is for me to try to resolve this with the Azure SDK project. I have concerns about how long that might take however, and in the meantime we have an implementation that does not work well for Azure. I can see two possible workarounds, neither of which I like: - Encode the filename in the "filename*" portion of the header twice, let the Azure SDK mess around with it when signing the URI, then fix it back to what it should be before sending the URI back to the client. It is an ugly hack but appears to work in the testing. - Don't include the "filename*" portion of the header at all, which would mean that filenames with special characters wouldn't be supported Either fix would probably have to be done to trunk and backported to 1.10, and then fixed again in both branches (plus any newer releases) once there was a fix in Azure - if that happens. Looking for feedback on this. WDYT? -MR
