I'm currently implementing the Engine.IO (and possibly Socket.IO) protocol in Pike (bidirectional realtime communication with JavaScript clients).
While doing so I noticed (to my dismay) that in WebSocket, I find the following code snippet:
protected int parse_variables() { if (has_index(request_headers, "sec-websocket-key")) return 0; return ::parse_variables(); }
I.e. parse_variables() is skipped on real websocket connections. What would be the reason why this is being skipped? I need to parse the variables on the URL of the soon-to-be-upgraded websocket connection; so it would be more convenient if it was handled automatically.
Yes, I agree that having the query string parsed is be very useful. There is some other logic in parse_variables() which we do not want, so we would have to make sure that none of that has any side effects. I would propose we explicitly call only the query decode and flatten_headers().
Arne
On 09/15/16 18:21, Stephen R. van den Berg wrote:
I'm currently implementing the Engine.IO (and possibly Socket.IO) protocol in Pike (bidirectional realtime communication with JavaScript clients).
While doing so I noticed (to my dismay) that in WebSocket, I find the following code snippet:
protected int parse_variables() { if (has_index(request_headers, "sec-websocket-key")) return 0; return ::parse_variables(); }I.e. parse_variables() is skipped on real websocket connections. What would be the reason why this is being skipped? I need to parse the variables on the URL of the soon-to-be-upgraded websocket connection; so it would be more convenient if it was handled automatically.
Arne Goedeke wrote:
Yes, I agree that having the query string parsed is be very useful. There is some other logic in parse_variables() which we do not want, so we would have to make sure that none of that has any side effects. I would propose we explicitly call only the query decode and flatten_headers().
I'll commit something to that effect.
Stephen R. van den Berg wrote:
Arne Goedeke wrote:
Yes, I agree that having the query string parsed is be very useful. There is some other logic in parse_variables() which we do not want, so we would have to make sure that none of that has any side effects. I would propose we explicitly call only the query decode and flatten_headers().
I'll commit something to that effect.
Committed, please review (both on 8.0 and 8.1).
Hi Stephen,
On 20 Sep 2016, at 09:59 , Stephen R. van den Berg srb@cuci.nl wrote:
Stephen R. van den Berg wrote:
Arne Goedeke wrote:
Yes, I agree that having the query string parsed is be very useful. There is some other logic in parse_variables() which we do not want, so we would have to make sure that none of that has any side effects. I would propose we explicitly call only the query decode and flatten_headers().
I'll commit something to that effect.
Committed, please review (both on 8.0 and 8.1).
Commit 7ce9c4ae introduced an incompatible API change in HTTP.Server.Request.parse_variables. We have an inheriting class that calls parse_variables() without arguments, which now fails to compile. Should the new parameter “short” be declared “void|int” ?
Regards, /Marty
Martin Karlgren wrote:
On 20 Sep 2016, at 09:59 , Stephen R. van den Berg srb@cuci.nl wrote:
Stephen R. van den Berg wrote:
Arne Goedeke wrote:
Yes, I agree that having the query string parsed is be very useful. There is some other logic in parse_variables() which we do not want, so we would have to make sure that none of that has any side effects. I would propose we explicitly call only the query decode and flatten_headers().
I'll commit something to that effect.
Committed, please review (both on 8.0 and 8.1).
Commit 7ce9c4ae introduced an incompatible API change in HTTP.Server.Request.parse_variables. We have an inheriting class that calls parse_variables() without arguments, which now fails to compile. Should the new parameter ???short??? be declared ???void|int??? ?
void|int will do. Fixed and committed to 8.0 and 8.1 just now.
Commit 7ce9c4ae introduced an incompatible API change in HTTP.Server.Request.parse_variables. We have an inheriting class that calls parse_variables() without arguments, which now fails to compile. Should the new parameter âshortâ be declared âvoid|intâ ?
Looks reasonable.
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Martin Karlgren -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum -
Stephen R. van den Berg