add support for application/x-www-form-urlencoded about katt HOT 8 CLOSED

wdyt, @sstrigler @isakb ?

from katt.

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 [email protected] 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 #49 (comment), or mute the thread https://github.com/notifications/unsubscribe/AABc6s6jwvEvDxhZAgv3xYDx_9GfDHK6ks5qN_6qgaJpZM4I62A2.

from katt.

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.

from katt.

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 [email protected] 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 #49 (comment), or mute the thread https://github.com/notifications/unsubscribe/AABc6ukHyE3aoB6f_hpqfJSWJqY7hH38ks5qOAQSgaJpZM4I62A2.

from katt.

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.

from katt.

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 [email protected] 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 #49 (comment), or mute the thread https://github.com/notifications/unsubscribe/AABc6q3O9PSAENnK9n45BwMfCQBTx4ZQks5qOAd-gaJpZM4I62A2.

from katt.

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 [email protected]:

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 [email protected] 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 #49 (comment), 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.

from katt.

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

+/- 0
🎱

from katt.