Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

json values are people too, two #968

Merged
merged 1 commit into from
May 8, 2018
Merged

json values are people too, two #968

merged 1 commit into from
May 8, 2018

Conversation

rdallman
Copy link
Contributor

@rdallman rdallman commented May 2, 2018

related: fnproject/fdk-go#26

adds a test for the protocol dumping of a request to the container stdin.
there are a number of vectors to test for a cloud event, but since we're going
to change that behavior soon it's probably a waste of time to go about doing
so. in any event, this was pretty broken. my understanding of the cloud event
spec is deepening and the json stuff still seems a little funky.

  • fixes content type issue around json checking (since a string is also a json
    value, we can just decode it, even though it's wasteful it's more easily
    correct)
  • doesn't force all json values to be map[string]interface{} and lets them be
    whoever they want to be. maybe their dads are still proud.

closes #966

@rdallman rdallman requested review from denismakogon and treeder May 2, 2018 02:40
Copy link
Contributor

@treeder treeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure this is incorrect.

If the contentType value is "application/json", or any media type with a structured +json suffix, the implementation MUST translate the data attribute value into a JSON value, and set the data member of the envelope JSON object to this JSON value.

Will also break ruby fdk too.

@rdallman
Copy link
Contributor Author

rdallman commented May 2, 2018

I'm pretty sure this is incorrect.

https://github.com/cloudevents/spec/blob/master/json-format.md#23-mapping-object-typed-attributes

the spec and the json spec seem to have different opinions about... a lot. sigh.

@rdallman
Copy link
Contributor Author

rdallman commented May 4, 2018

I filed cloudevents/spec#184 in hopes the cloud events gods will shine their benevolent light upon us

adds a test for the protocol dumping of a request to the containert stdin.
there are a number of vectors to test for a cloud event, but since we're going
to change that behavior soon it's probably a waste of time to go about doing
so. in any event, this was pretty broken. my understanding of the cloud event
spec is deepening and the json stuff overall seems a little weird.

* fixes content type issue around json checking (since a string is also a json
value, we can just decode it, even though it's wasteful it's more easily
correct)
* doesn't force all json values to be map[string]interface{} and lets them be
whoever they want to be. maybe their dads are still proud.

closes #966
@fnproject fnproject deleted a comment from fn-bot May 7, 2018
@fnproject fnproject deleted a comment from fn-bot May 7, 2018
@rdallman
Copy link
Contributor Author

rdallman commented May 8, 2018

@treeder i think we agree meow ?

@rdallman
Copy link
Contributor Author

rdallman commented May 8, 2018

thanks

@rdallman rdallman merged commit 1f16247 into master May 8, 2018
@rdallman rdallman deleted the test-proto-ce branch May 8, 2018 05:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent content type check for cloudevent response
3 participants