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

fix: make application/json the default content type in binary mode #118

Merged
merged 1 commit into from
May 5, 2020

Conversation

lance
Copy link
Member

@lance lance commented May 4, 2020

The Knative Kafka event source does not include a Content-Type header when
sending binary events. The CE HTTP binding specification doesn't address how
a receiver should handle this situation.

This commit makes application/json the default.

Fixes: #117
Ref: cloudevents/spec#614

Signed-off-by: Lance Ball lball@redhat.com

The Knative Kafka event source does not include a `Content-Type` header when
sending binary events. The CE HTTP binding specification doesn't address how
a receiver should handle this situation.

This commit makes `application/json` the default.

Fixes: cloudevents#117
Ref: cloudevents/spec#614

Signed-off-by: Lance Ball <lball@redhat.com>
@lance lance merged commit d9e9ae6 into cloudevents:master May 5, 2020
grant pushed a commit to grant/sdk-javascript that referenced this pull request May 6, 2020
…loudevents#118)

The Knative Kafka event source does not include a `Content-Type` header when
sending binary events. The CE HTTP binding specification doesn't address how
a receiver should handle this situation.

This commit makes `application/json` the default.

Fixes: cloudevents#117
Ref: cloudevents/spec#614

Signed-off-by: Lance Ball <lball@redhat.com>
Signed-off-by: Grant Timmerman <timmerman+devrel@google.com>
grant added a commit to grant/sdk-javascript that referenced this pull request May 6, 2020
grant added a commit to grant/sdk-javascript that referenced this pull request May 6, 2020
… mode (cloudevents#118)"

This reverts commit 9ccfaf2.

Signed-off-by: Grant Timmerman <timmerman+devrel@google.com>
grant added a commit that referenced this pull request May 6, 2020
* fix: make application/json the default content type in binary mode (#118)

The Knative Kafka event source does not include a `Content-Type` header when
sending binary events. The CE HTTP binding specification doesn't address how
a receiver should handle this situation.

This commit makes `application/json` the default.

Fixes: #117
Ref: cloudevents/spec#614

Signed-off-by: Lance Ball <lball@redhat.com>
Signed-off-by: Grant Timmerman <timmerman+devrel@google.com>

* refactor: remove ext folder

Signed-off-by: Grant Timmerman <timmerman+devrel@google.com>

* Revert "fix: make application/json the default content type in binary mode (#118)"

This reverts commit 9ccfaf2.

Signed-off-by: Grant Timmerman <timmerman+devrel@google.com>

Co-authored-by: Lance Ball <lball@redhat.com>
lance added a commit to lance/sdk-javascript that referenced this pull request May 7, 2020
The fix provided in cloudevents#118
only included tests for `receiver.check()`, and the change in that
case was to add the `application/json` content type to the cleansed
headers if to type was specified.

However, `receiver.parse()` did not receive the benefit of this change. It
calls `this.check()` but then sanitizes the original headers again, and the
missing content-type was not re-inserted into the newly sanitized headers.

This commit, modifies the code so that `receiver.check()` does not insert
the content-type, but does allow the validation check to pass if no
content-type header exists. When `receiver.parse()` is called, and the
headers are sanitized again - and this time used to look up parser implementation,
the default `application/json` content-is applied if no content-type header
exists.

I've also removed a redundant call to `receiver.check()` in receiver_binary_1.js
and simplified the usage of `Constants` in the test.

Signed-off-by: Lance Ball <lball@redhat.com>
lance added a commit that referenced this pull request May 9, 2020
* fix: ensure binary events can handle no content-type header

The fix provided in #118
only included tests for `receiver.check()`, and the change in that
case was to add the `application/json` content type to the cleansed
headers if to type was specified.

However, `receiver.parse()` did not receive the benefit of this change. It
calls `this.check()` but then sanitizes the original headers again, and the
missing content-type was not re-inserted into the newly sanitized headers.

This commit, modifies the code so that `receiver.check()` does not insert
the content-type, but does allow the validation check to pass if no
content-type header exists. When `receiver.parse()` is called, and the
headers are sanitized again - and this time used to look up parser implementation,
the default `application/json` content-is applied if no content-type header
exists.

I've also removed a redundant call to `receiver.check()` in receiver_binary_1.js
and simplified the usage of `Constants` in the test.

Signed-off-by: Lance Ball <lball@redhat.com>

* chore: clean up header sniffing

Signed-off-by: Lance Ball <lball@redhat.com>
lance added a commit to lance/sdk-javascript that referenced this pull request May 9, 2020
…nts#134)

* fix: ensure binary events can handle no content-type header

The fix provided in cloudevents#118
only included tests for `receiver.check()`, and the change in that
case was to add the `application/json` content type to the cleansed
headers if to type was specified.

However, `receiver.parse()` did not receive the benefit of this change. It
calls `this.check()` but then sanitizes the original headers again, and the
missing content-type was not re-inserted into the newly sanitized headers.

This commit, modifies the code so that `receiver.check()` does not insert
the content-type, but does allow the validation check to pass if no
content-type header exists. When `receiver.parse()` is called, and the
headers are sanitized again - and this time used to look up parser implementation,
the default `application/json` content-is applied if no content-type header
exists.

I've also removed a redundant call to `receiver.check()` in receiver_binary_1.js
and simplified the usage of `Constants` in the test.

Signed-off-by: Lance Ball <lball@redhat.com>

* chore: clean up header sniffing

Signed-off-by: Lance Ball <lball@redhat.com>
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.

Support for lack of content-type header in binary mode parsing
3 participants