pvillard31 commented on PR #9842: URL: https://github.com/apache/nifi/pull/9842#issuecomment-2775845450
> For Header Names, I think we should be careful on the boundaries of what to include. Various RFC documents define standard headers, and other headers have become de facto standards. One other potential issue is that HTTP/2 lowercases header names. Most HTTP clients handle this translation for requests internally, but handling responses becomes more challenging. That reason alone makes me think that defining header names could be problematic when it comes to expecting particular HTTP protocol versions of client behavior. Definitely agree with you but the problem would remain for every individual implementation, wouldn't it? The idea of the enum is to make it easier and provide something that can be reused for the most common use cases I've came across but it does not mean that it has to be used if it does not fix the implementation relying on the NiFi Web Client. Happy to keep this limited to a small set of values. > It may be worth considering a separate module, such as nifi-web-client-shared, which includes these enumerations, but does not carry the same implications of the API, which is part of the nifi-web-client-provider-api Controller Service definition. I don't have any strong opinion on this to be honest. I was really thinking on how to make it easy for consumers of that API to leverage those enums in the various implementations. If we think a dedicated module is the way to go, I'm ok with it, but based on what I see, every implementation would have to bring this module in. I pushed a commit with a more scoped set of changes. Let me know what you think. -- 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]
