Add status code 308

[glassfishrobot]

RFC 7538 describes the behavior of the HTTP status code 308. While this RFC is quite new it solves an actual problem regarding POST redirections.

And it completes quite well the 307 status code found in the HTTP 1.1 RFC (previously described in the obsolete RFC 2616).

[glassfishrobot]

@mithunsasidharan Commented
@bric3 : https://github.com/jax-rs/api/pull/577

[glassfishrobot]

@bric3 Commented
Great thanks !

[glassfishrobot]

@mithunsasidharan Commented
@bric3 : thank you. Kindly review merge 👍

[glassfishrobot]

• Issue Imported From: https://github.com/jax-rs/api/issues/573
• Original Issue Raised By:@bric3
• Original Issue Assigned To: Unassigned

[mkarg]

-1, as this RFC is a draft only and it won't be possible due to WORA to remove support of 308 in case it never reaches public standard status.

[bric3]

@mkarg Yet almost every browser already handle this status : https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308.

Also, most of the time REST APIs will be the target of applicative clients (mobile apps, servers, js apps, etc.).

While it doesn't justify to add this status code, I'd like to point out that in the history browsers implemented a long list of draft RFC before becoming an Internet Standard, e.g. WebRTC).

[mkarg]

@bric3 You missed my point. RFCs have statuses for good reason. JAX-RS, as any official Java standard, cannot go back. A feature, once there, must stay for virtually ever. In case the RFC will be replaced, we cannot adopt the final one. So there is no other solution (due to WORA) as to wait until the RFC is an official standard.

[spericas]

I understand Markus' point. However, this RFC has been around for 3 years and there is very good support for it. Given it's rather narrow scope, I don't see a problem considering it for inclusion.

[jansupol]

Just a note, for the first release of EE4J, a backward compatible API should be released first. I believe this merge would break the backward compatibility

[bric3]

Agreed I understand @mkarg point, but given that all (recent) browsers already supports it, there's little possibility this RFC to be abandoned.

@mkarg Do you think it would be acceptable to have a dedicated class or annotation for pending approval status (e.g. @Beta)

[mkarg]

@jansupol This merge would not break anything, as certainly any new features have to go into a branch separate from the one for initial Java EE 8 proof-of-compliance.

[mkarg]

@bric3 What will you do in case the undoubtly very very very unlikely case happens and the RFC does get abandoned? And no, as this is a normative project and not an just some implementation, I do not think it would be a good idea to add anything the like @Beta. What we can do, and I support that, is adding a branch for experimental features and add the feature there.

[sdaschner]

I also disagree to add something like @Beta. At least if we aim to continue being a standard. Other approaches, such as using an incubator project, a different branch with code that won't make it to the regular branch (at first), or else should be preferred IMO.

I also agree with @jansupol that we need to have a "EE.next 1.0" release first.