Missing status codes in Response class

[reschke]

See #582, which was closed for reasons that escape me.

There are likely more status codes missing, see the IANA registry at https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml. It would also be good to update comments to refer to current RFCs, not obsoleted ones.

cc: @mkarg

[spericas]

The reason is there:

"@mithunsasidharan Are you still interested in working on this? If so, could you rebase against `3.1-SNAPSHOT" and update the pull request accordingly?"

Needs to be resubmitted for 3.1 using the correct branch.

[mithunsasidharan]

@spericas : Is this something thats already been pickedup ? If not I'd like to work on it !

[spericas]

@mithunsasidharan Feel free to work on it. See previous work and suggestion by @reschke.

[spericas]

@mithunsasidharan Any update on this work?

[jelemux]

If @mithunsasidharan isn't responding, I'd be willing to tackle this.
Maybe we wait a week or so and if we hear nothing, I'll create a PR?
Is that okay for everybody? @spericas @mkarg WDYT?

[mkarg]

@jelemux There wer months of waiting, so I'd say, he lost interest. Please go ahead, we would be delighted to receive your PR.

[jelemux]

Thank you @mkarg!

I suppose there's a reason that there are no 100 status codes in there, right?
Any other status codes that have been left out by choice and that I should not add?

[mkarg]

JAX-RS is not an HTTP wrapper (like Servlet API), it is solely and specifically a REST API, hence not all the codes make sense. So I would say, only those should be added that really are of general interest for REST applications.

[jelemux]

Sorry for the late response, I've caught the flu and then had a week of vacation after I recovered.

I went through all the missing status codes and singled those out that MAY be of general interest for REST applications.
I've documented my findings on this wiki page. Feel free to go through them and comment your opinions here.

In short, those are the status codes that may be of general interest to REST applications:

• 203 Non-Authoritative Information
• 300 Multiple Choices
• 308 Permanent Redirect
• 451 Unavailable For Legal Reasons

I think it is best to create separate PRs for each of these since there may be arguments against some of these that don't concern the others.
The only exception being the argument that those are all only Proposed Standard RFCs, which has already been discussed, but with no clear conclusion (to me). Does this argument still stand?

[jelemux]

What may not be of general interest to REST applications but still came up is WebDAV.
The JAXRS specification states under goals:

The API will provide high level support for common HTTP usage patterns and will be sufficiently flexible to support a variety of HTTP applications including WebDAV and the Atom Publishing Protocol.

Because additional status codes can be added by creating an implementation of StatusType, it is my opinion that this goal is fulfilled since the API is sufficiently flexible. If you (and others) agree, then I don't think that further discussion on this topic is necessary.

[andymc12]

@jelemux I agree with your assessment on the wiki. I'm +1 for adding 300, 308 and 451. I'm +0 or -1 on the rest. I also agree that separate PRs would be the most expedient - I suspect that 308 will be the easiest to get in, while 300 and 451 might take some discussion. Thanks for putting this together! I think it will also help us in the future (for example, when JAX-RS officially supports HTTP/2, etc.) to know which HTTP response codes we should add.

[mkarg]

I never needed 203; I doubt that it is actually of common use.

WebDAV is definitively an outdated technology which we should not start to explicitly support. In fact, if someone wants to use WebDAV with JAX-RS, he can simply use the ready-to-use extension WebDAV for JAX-RS which (for those who don't know) was the reason for me adding the StatusType interface back then, and which in fact simply does what you propose... (it's always good to know some history ;-) ).

[jelemux]

Now that the codes have been added, I think this can be closed now.