>> In fact, what is it with this list? Is this the PUT Haters Club? > > Mainly, it is your attitude. Given you are speaking to a community that > provides assistance to other members of the community for free, a less > argumentative tone would go a long way to help.
Ah. I think I see where the problem lies. You think I came here to get something from you, and so you feel justified in making me jump through hoops to get it. But you have it backwards. I already had a workaround when I came to the list. And I'm pretty sure I'm going to abandon Tomcat anyway in favor of Jetty, or maybe something bigger. I posted to this list to help you. I was letting you know about a potential problem with Tomcat, and offering to help track down whether it was actually Tomcat that was causing that behavior or not. It seems counterproductive to me to attack people who come to help, but maybe that's just me. If I seem argumentative to you, consider that I've put in several hours on this trying to help and provide answers to people -- even when the questions are not germane. I've even backed everything up with evidence. And what I've gotten for my troubles is, frankly, nothing but grief. I am no further ahead than I was before I contacted the list, and I've spent time that I really can't afford to spend. > >> Why do I have to defend my decision to use PUT requests? > > When one of the possible solutions is a work-around and that work-around > may involve using a method other than PUT then I think it is fair for > folks to question the absolute need to use PUT. Workarounds are only solutions to people who care only for immediate relief, even if it costs them dearly down the road. A true solution doesn't require a workaround -- it fixes the problem. If you accept workarounds, then it won't be long before you find your code base an unmaintainable mess. I have a workaround. What I'm looking for is a solution, and using a POST for what should be a PUT is not a solution. At best, it's a hack. > >> Why do I have to keep >> explaining an RFC that should be near and dear to the hearts of anyone >> who >> works with web servers? > > Perhaps if you were using the correct terminology (entity body rather > than entity headers) folks here would find it easier to understand you. > Hassan was pointing out the correct way to use entity headers. You are > trying to use an entity body. If this was really Hassan's intent, then it might have been clearer if he said, "I think you are confusing the entity-body with the entity-headers. The paramaters that are being passed are actually the entity-body." I could live with that interpretation, although if you showed the parameters in the HTTP headers to virtually anyone I know, he or she would say "those are headers." So if you are right, it is actually at the expense of clear communication, rather than the reverse. But this brings up a good question. I used a Request Dumper Valve (at the suggestion of another person on this list) to check what Tomcat was getting. Although the parameters were definitely passed with the request, they were not present in the dump. The dump showed all the headers. Is the message body not included in the dump? If so, maybe that's where the parameters went. That would be an actual solution, and, in fact, it is where I believe RFC 2616 expects them to be. But note that the parameters are passed in *exactly* the same way in a POST and a PUT. When POSTed, there they are in the Dumper output. When PUTted, there they are not. If the RDV only dumps HTTP headers, and it dumps the parameters in a POST, then they are headers and should be in the PUT. If they are message body in the PUT, then so should they be in the POST, hence they should not be in the dump. Something is not consistent here. > >> What does *any* of this have to do with a simple >> post to the list explaining that parameters passed with a PUT request >> seem >> to be stripped out by Tomcat (though not by Jetty), and asking if this >> was >> a bug or intended behavior? > > I'll address that by replying to your other post that appears to have > identified the root cause. > > Mark > > > > --------------------------------------------------------------------- > 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
