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.

[mkarg]

@sdaschner While I share the vision of the PMC that Java EE 8 compliance is first priority in general, everybody is free to work on things he likes. So if someone needs a sandbox that will possibly never make it into master at all, he is free to add an experimental branch in his own fork.

[ronsigal]

Does anyone have a sense of what it means that https://tools.ietf.org/html/rfc7538 has remained a Proposed Standard for over five years? https://datatracker.ietf.org/doc/rfc2026/ "The Internet Standards Process -- Revision 3" says that, "A specification shall remain at the Proposed Standard level for at least six (6) months", and that

When a standards-track specification has not reached the Internet
Standard level but has remained at the same maturity level for
twenty-four (24) months, and every twelve (12) months thereafter
until the status is changed, the IESG shall review the viability of
the standardization effort responsible for that specification and the
usefulness of the technology.

Obviously, it hasn't been terminated, but, for what seems like a relatively straightforward proposal, isn't five years a long time?

[chkal]

My guess is that this RFC is abandoned. But I may be wrong about this.

However, it is listed on the HTTP WG site and in the IANA HTTP Status Code Registry. Therefore, and because all browsers support it, I would be fine with adding it, even if the RFC isn't final (yet).

[ronsigal]

would be fine with adding it, even if the RFC isn't final (yet).

That seems reasonable to me. I wonder if anyone has any connections at IETF that could shed some light on why https://tools.ietf.org/html/rfc7538 has been languishing for so long. Just curious.

[ronsigal]

I reached out at Red Hat about this and got an interesting response:

I don't think any part of HTTP has made it to 'Internet Standard', only 'Proposed Standard'. ... The original HTTP/1.1 was only a Draft Standard, the HTTP/1.1 is proposed, as is HTTP/2.

I don't know why that is, but I guess that's the way that part of the world works (or doesn't). But I feel better now.

[ronsigal]

I will ask Julian (the author of RFC 7538)

That's a great idea. It seems ... curious ... that HTTP remains in a proposed state. Maybe they think it's not going to catch on. ;-)

[reschke]

Please ignore the status on the Standards Track. This part of RFC 2026 is defunct and has never been followed.

Right now, both RFC 7538 and the base HTTP specs are in status "proposed".

Note that the IETF HTTPbis WG is working on a revision of RFCs 723*, and that actually inlines the definition of status code 308. It's all on Github, see https://github.com/httpwg/http-core.

[mkarg]

@reschke Thanks for being so kind to chime in, and thanks for the private comments you sent me on RFC 2026. :-)