kevdoran commented on pull request #5475: URL: https://github.com/apache/nifi/pull/5475#issuecomment-959182309
@ottobackwards my understanding is that the `invokehttp.request|response.url` attributes contain the full url, where as the new filename attribute is just the leaf of the path, correct? ie ``` invokehttp.request.url = https://example.com/path/to/my-file.txt filename = my-file.txt ``` In this case, we are only deciding if that file name should be url encoded, e.g., `filename%20with%20spaces%20and%2Fslashes.txt` or `filename with spaces and/slashes.txt` I think we can make an argument for either approach. Where backward compatibility comes into play is thinking about existing flows and assumptions they may make about the filename attribute. For example: ``` InvokeHTTP >> PutS3 ``` Currently, the filename used for S3 object key will be the flowfile UUID. This PR will change that to be the filename, which if it is url encoded will still work with PutS3, but if it is decoded will break if the filename contains special characters such as `/`. For this reason, I vote leaving filename url encoded in InvokeHTTP, but I don't feel strongly! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
