add support for application/x-www-form-urlencoded

[andreineculau]

i.e. allow for a nice DSL to send in urlencoded key-value dictionaries

possible suggestion is to base this on JSON, on the condition that the first character of the payload is {, else default to plain text:

POST /foo
> Content-Type: application/x-www-form-urlencoded
{
  "key1": "http://example.com",
  "key2": "a=b"
}

would be the equivalent of

POST /foo
> Content-Type: application/x-www-form-urlencoded
key1=http%3A%2F%2Fexample.com&key2=a%3Db

[andreineculau]

wdyt, @sstrigler @isakb ?

[sstrigler]

Feels weird. Setting content-type to 'application/x-www-form-urlencoded' and then sending sth different...

On 21 juni 2016, at 17:09, Andrei Neculau notifications@github.com wrote:

wdyt, @sstrigler https://github.com/sstrigler @isakb https://github.com/isakb ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/for-GET/katt/issues/49#issuecomment-227470800, or mute the thread https://github.com/notifications/unsubscribe/AABc6s6jwvEvDxhZAgv3xYDx_9GfDHK6ks5qN_6qgaJpZM4I62A2.

[andreineculau]

you still send application/x-www-form-urlencoded, but with a JSON DSL. We already have that today

POST /foo
some{{<bar}}

is not that different, right? You do send "somequx" if bar = qux.

[sstrigler]

Yeah, you're right. Mind boggling! B)

What if...

POST /foo

Content-Type: application/x-www-form-urlencoded {{<payload}}

And then what if 'payload' is

{ "key1": "http://example.com http://example.com/", "key2": "a=b" }

On 21 juni 2016, at 17:32, Andrei Neculau notifications@github.com wrote:

you still send application/x-www-form-urlencoded, but with a JSON DSL. We already have that today

POST /foo some{{<bar}} is not that different, right? You do send "somequx" if bar = qux.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/for-GET/katt/issues/49#issuecomment-227478318, or mute the thread https://github.com/notifications/unsubscribe/AABc6ukHyE3aoB6f_hpqfJSWJqY7hH38ks5qOAQSgaJpZM4I62A2.

[andreineculau]

I don't see how that plays into this. We only parse the DSL once, not twice, not until it stabilizes. If payload was "{{<payload2}}", regardless of the content-type, it's not like we would expand payload2.

[sstrigler]

Ok ok, but know you've read my comment as just one remark. At least I think so.

My first concern is that when you have old style blueprints that start with a {{<param}} with the new DSL you'd think that's a JSON that follows. So you probably have to make sure there is no second { before interpreting as the new DSL.

No?

On 21 juni 2016, at 17:47, Andrei Neculau notifications@github.com wrote:

I don't see how that plays into this. We only parse the DSL once, not twice, not until it stabilizes. If payload was "{{<payload2}}", regardless of the content-type, it's not like we would expand payload2.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/for-GET/katt/issues/49#issuecomment-227482847, or mute the thread https://github.com/notifications/unsubscribe/AABc6q3O9PSAENnK9n45BwMfCQBTx4ZQks5qOAd-gaJpZM4I62A2.

[andreineculau]

Aha, I see. That is a valid concern but I guess i should clarify the detection rule (i.e. "{[^{]" since that's not valid JSON), thus make it more specific, or say that we now try parsing as JSON and use the DSL, and on failure we default to simple text, like before.

Worth thinking about.

21 juni 2016 kl. 18:07 skrev Stefan Strigler notifications@github.com:

Ok ok, but know you've read my comment as just one remark. At least I think so.

My first concern is that when you have old style blueprints that start with a {{<param}} with the new DSL you'd think that's a JSON that follows. So you probably have to make sure there is no second { before interpreting as the new DSL.

No?

On 21 juni 2016, at 17:47, Andrei Neculau notifications@github.com wrote:

I don't see how that plays into this. We only parse the DSL once, not twice, not until it stabilizes. If payload was "{{<payload2}}", regardless of the content-type, it's not like we would expand payload2.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/for-GET/katt/issues/49#issuecomment-227482847, or mute the thread https://github.com/notifications/unsubscribe/AABc6q3O9PSAENnK9n45BwMfCQBTx4ZQks5qOAd-gaJpZM4I62A2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[isakb]

I am a bit skeptical, but can see the pain of having to application/x-www-form-urlencoded payloads.

+/- 0 🎱