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

HttpHeader for Expect #900

Closed
senivam opened this issue Aug 26, 2020 · 7 comments · Fixed by #903
Closed

HttpHeader for Expect #900

senivam opened this issue Aug 26, 2020 · 7 comments · Fixed by #903
Assignees
Labels
Milestone

Comments

@senivam
Copy link
Contributor

senivam commented Aug 26, 2020

will it be possible to add after this line HttpHeader for Expect?

    /**
     * See <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20">HTTP/1.1 documentation</a>.
     */
    public static final String EXPECT = "Expect";

this is required to provide support for HTTP 100-continue handling (see related Jersey bug about this)

@andymc12
Copy link
Contributor

Yes, I think it makes sense to add the Expect header to the list in HttpHeaders. Can you open a pull request adding these lines? Make sure to target the 3.1-SNAPSHOT release since we cannot add it to the 3.0 (master) release. Thanks!

@mkarg
Copy link
Contributor

mkarg commented Aug 27, 2020

@andymc12 I agree with you, but just for my own curiosity: What do you expect to break if we add a new static String to this interface? IMHO it would be safe to do it even in master, as nobody would say this is really a feature, and we keep backwards compatibility.

@mkarg mkarg self-assigned this Aug 27, 2020
@mkarg mkarg added the api label Aug 27, 2020
@mkarg mkarg added this to the 3.1 milestone Aug 27, 2020
@senivam
Copy link
Contributor Author

senivam commented Aug 27, 2020

so, just to be clear, shall I do the PR or @mkarg will do that? And how to proceed? :)

@andymc12
Copy link
Contributor

@mkarg

What do you expect to break if we add a new static String to this interface? IMHO it would be safe to do it even in master, as nobody would say this is really a feature, and we keep backwards compatibility.

Nothing should break, afaik, but my understanding was that Jakarta EE 9 was supposed to be binary compatible with Jakarta EE 8 except for the package name change. I would also recommend putting this into 3.1 since @spericas just released 3.0 - I think we could probably re-spin the release, but even if it is allowed to add to 3.0, I don't think this change is worth the trouble to re-spin. If others think strongly that it should go into 3.0, I can be persuaded - but we'd probably want somebody from the platform community to approve first. @spericas @kwsutter @ivargrimstad wdyt?

@senivam if you are ok with waiting until 3.1, then you could open the pull request. If you want to push for inclusion into 3.0, then I would suggest waiting until Santiago or somebody from the platform committee agrees. Thanks!

@spericas
Copy link
Contributor

Yes, this should be 3.1. Looks like @mkarg already set that.

@mkarg mkarg linked a pull request Aug 27, 2020 that will close this issue
@mkarg
Copy link
Contributor

mkarg commented Nov 7, 2020

@senivam Do you confirm that your wanted changes are contained in the 3.1 branch, so we can close this issue? Thanks.

@senivam
Copy link
Contributor Author

senivam commented Nov 7, 2020

@mkarg yes, sure, the issue can be closed as resolved. Thank you.

@senivam senivam closed this as completed Nov 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants