Block remote adapter url and handler override #1147
Conversation
| @@ -92,6 +92,11 @@ public Input parseRequest(FullHttpRequest req, QueryStringDecoder decoder) { | |||
| byte[] content = NettyUtils.getBytes(req.content()); | |||
| input.add("data", content); | |||
| } | |||
|
|
|||
| if (input.getProperties().containsKey("handler")) { | |||
| throw new BadRequestException("The handler can't be overridden in a request"); | |||
There was a problem hiding this comment.
Why we want to block handler override?
This at least should be an option (a global conf.properties) to disable handler override if we want disable it.
There was a problem hiding this comment.
I wrote a comment about this in slack
There was a problem hiding this comment.
@frankfliu If we want to support this, I think it should be a property to enable rather than disable. Do you know if we have users using custom handlers now?
There was a problem hiding this comment.
This was designed to allow user to call pre/postprocessing:
https://github.com/deepjavalibrary/djl-demo/tree/master/development/python
There was a problem hiding this comment.
We can default to disable handler override
There was a problem hiding this comment.
After more thought, I don't think it is something we want to support at all. But, here are two workarounds that give very similar results:
1 - Share model.py
We keep the ability to change the handler in the serving.properties. Then, you can symlink the model.py around to share it. This will still result in different workers for the model and pre-post processing unless we change something.
2 - Sub-handler
subHandlers = {
"pre" : (lambda inputs: ...),
"m" : (lambda inputs: ...),
"post" : (lambda inputs: ...),
}
def handler(inputs):
return subHandlers[inputs.getProperty("subHandler")](inputs)There was a problem hiding this comment.
I think we can leave this discussion for later. For now, I added an env/system prop ALLOW_REQUEST_HANDLER_OVERRIDE to re-enable handler overrides
No description provided.