Update wagi.rs

[guyoung]

modify parse WagiHttp request params to command-line arguments

[itowlson]

This change seems to alter the behaviour to ignore wagi_config. Can you say more about what you intend with this change?

[guyoung]

In my project AIMatrices(https://github.com/guyoung/AIMatrices), a large amount of code from the Spin project is referenced. There is a requirement to run Python code using wagi, and the http requests are as follows:

• http://127.0.0.1:21500/python?-h
• http://127.0.0.1:21500/python?-c=print(1)
• http://127.0.0.1:21500/python?-c&print(1)
• http://127.0.0.1:21500/python?-c&import sys; print(sys.version)

Currently, the parameter parsing method of WagiHttpExecutor cannot meet the above http requests.

[itowlson]

Thanks for the clarification. The WAGI executor an argv template from configuration, and we can't just throw that away. For example, a Spin app could set:

executor = { type = "wagi", argv = "my-first-value ${SCRIPT_NAME} my-middle-value ${ARGS} my-last-value"

and your proposed change would break that.

I'm guessing the big problem is the way that the implementation splits the post-substitution argv on spaces, so your query string of http://127.0.0.1:21500/python?-c&import sys; print(sys.version) gets turned into an args of ["-c", "import", "sys;", "print(sys.version)"] or something like that?

If so, maybe the fix is to change how we use the template. Currently we sub into the template string, then split the post-substitution argv on spaces to get an args iterator. Maybe the better strategy is to split the template string on spaces first, then splice in the array of query-string pairs at the position of the ${ARGS} element. That seems like it might meet your needs while retaining backward compatibility with argv templates. Thoughts?

[guyoung]

I agree with you