REST -- REpresentational State Transfer -- is an architectural style that
was developed by Roy Fielding with HTTP, but which is independent of HTTP.
No changes need to be made to HTTP to implement REST -- you just need to
implement HTTP correctly. There's a pretty good article on Wikipedia about
REST, and you can always read Fielding's dissertation.

The issue here has nothing to do with REST. I was answering your question
about why I'm insisting on PUT rather than accepting POST as most people
do. The problem with Tomcat -- if it is indeed a problem with Tomcat -- is
that it is not implementing the HTTP 1.1 standard correctly. That's either
true or false, but it is unrelated to my desire to use Tomcat to host a
RESTful web service.

I am neither a Tomcat nor a Java developer, so a patch is not likely to
come from me, unless you want it in Scala. I can live with the POST
workaround for the moment. But if it is a bug in Tomcat, then it would be
nice if someone fixed it. I know several people who would be equally
concerned.

As for confirming Christopher's point, I'm not sure what you're referring
to. Someone posted five steps for me to take and post answers to, and I
did all five steps and posted the answers, albeit in two separate emails.
What did I miss?

I've submitted also a set of headers from a PUT request with an example of
the line that goes missing when delivered to Tomcat (but not when
delivered to Jetty).

Until someone who knows more about Tomcat than I do (probably everyone on
this list) confirms that the headers are actually being stripped, it's all
probably moot.

Chas.


> c...@munat.com wrote:
> ...
>>
>> So for Tomcat to unilaterally strip the entity-headers from a PUT
>> request
>> while passing only the optional entity-body seems just, well, wrong to
>> me.
>>
>> For this reason, I'm guessing it's a bug.
>>
> Hi.
> Just to situate things, I am not one of the Tomcat developers, merely a
> user. So whatever I say about Tomcat below is relatively speculative and
> under my own responsibility only.
> Furthermore, my knowledge of REST is very scarce, but I gather that it
> is a protocol/architecture (?) implemented, in this case, on top of HTTP.
> I am a long-time user of HTTP, so in that respect, if only by virtue of
> repetition, I feel on more solid ground.
>
> Tomcat is a servlet engine, and a HTTP server.  It is not a REST server
> nor client, and does not claim to be.
>
> This does not mean that you are wrong in your main contention; but means
> that if Tomcat does things right with respect to the Java Servlet Spec
> and the HTTP protocol, then Tomcat fulfills its contract, and whatever
> would be missing to also make it be a REST server would not be a bug,
> and merely an inconvenience.  And if so, you /might/ be able to persuade
> the developers of lifting the inconvenience, or better yet, submit a
> patch for ditto.
>
> In your previous posts, you have not been very clear about what you
> meant by "parameters", and later you have mentioned HTTP headers instead.
> If Tomcat was indeed "stripping" HTTP headers from a PUT request (iow
> making it impossible for a servlet to retrieve them), then I would tend
> to agree that this is a bug, because I see nothing in the HTTP spec that
> indicates that a PUT should not contain HTTP headers (at the contrary
> even).
>
> But is that really what happens ?
> Christopher asked you previously to confirm that point, but you didn't
> really.
> Or are you talking about parameters sent as part of the request line,
> like in a query string ?
> Can you give us an example of how you are sending these "parameters",
> and how exactly you (attempt to) retrieve them in the web application ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to