Arc Forumnew | comments | leaders | submitlogin
Keeping GET params in the case of a POST
6 points by immad 6106 days ago | 9 comments
Basically I had the issue that I was doing a POST to an arc url but I wanted to keep the parameters I was passing through GET as well.

I noticed that in the case of POST handle-request-thread (srv.arc) throws away the GET args. I made a little change to handle-post to take the following arguments

84 (def handle-post (i o op args n cooks ip)

And I call that in handle-request-thread by doing the following:

70 post (handle-post i o op args n cooks ip)

Lastly in handle-post itself, I combine the args with the POST args:

94 (respond o op (+ (parseargs (string (rev line))) args) cooks ip))))

Would be interested in what people think of doing it this way? Does this seem sensible? It means that all the get variables will be appended after the post variables, which seems pretty standard to me rather than throwing them away. I only just thought of this and only did limited testing so it may be entirely wrong :).



3 points by almkglor 6106 days ago | link

I think this is good. I suggest pushing this into nex3's arc-wiki.git

What I would really like to have, though, is something like this:

  (defop foo args
    (link "hmm" "something?arg1=value1&arg2=value2"))

  (defop something (arg1 arg2)
    (expr arg1 arg2))

-----

2 points by aston 6106 days ago | link

That isn't actually too hard. You'll want to write your own defop__ dealie, but essentially you can just pull the vars you want out of the req variable. before calling the rest of the body.

-----

2 points by almkglor 6106 days ago | link

No, it is. Because the problem is that there's a whole bunch of defop_ dealies. defopr, defop-raw. Sure, you can make a macro-making macro, but I think it's better if we start from the top and define it in defop-raw, so that everything that builds on top of it uses (arg1 arg2) syntax.

Of course, there might be subtleties involved here anyway.

-----

4 points by lojic 6106 days ago | link

Aren't POST & GET mutually exclusive?

-----

8 points by aston 6106 days ago | link

Technically no. I read up on the spec a while back. GET parameters are probably better referred to as URL args, and they're always retrievable via the URL in the first line of the HTTP request. In the case of a POST, the content of the request may (also) have arguments.

It's not super common to use both, but it's definitely not disallowed by the spec.

-----

1 point by lojic 6106 days ago | link

I'd be interested in seeing any references about this. From what I've read, it seems the intent is to not combine them, but I haven't seen anything explicitly forbidding it. Do you have a source that indicates combining URL parameters in a POST is encouraged, or at least permitted?

http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13....

-----

4 points by aston 6106 days ago | link

I never claimed "encouraged." I just said nothing disallows it. Browsers all seem cool with it, so why shouldn't your web server be?

-----

1 point by lojic 6106 days ago | link

Well the OP stated:

"I noticed that in the case of POST handle-request-thread (srv.arc) throws away the GET args."

Which seems to be criticizing what I would consider perfectly valid behavior. I'm not sure why you would want to split your parameters for a POST between the POST parameters and pieces of the URL.

If a change to the source is being suggested, it seems reasonable to determine if it's warranted by the protocol.

-----

5 points by immad 6106 days ago | link

I haven't checked the specs, but in most web languages I have worked with you can get GET parameters even when there is a POST. If this is not allowed by specs than I stand corrected. GET parameters are just stuck to the url so its definitely possible.. If its not allowed in theory then I stand corrected, I just often find it useful.

-----