Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <441f856a3213a40027852f0ce21e2f47.squirrel@mail.munat.com>
In-Reply-To: <4B6D69AB.2060508@apache.org>
References: <4B6AF961.4010901@ice-sa.com>
    <e0b108b3fcbd25e51f0fe03c29bf165b.squirrel@mail.munat.com>
    <4B6C9D43.6060905@christopherschultz.net>
    <1c6c2677a0b66b67fdd8747400f44fe1.squirrel@mail.munat.com>
    <4eedb92a1002051639o6ae5cf89m3a2484b077320a58@mail.gmail.com>
    <4fd043910c7d24732b0d4824ac1b9a9f.squirrel@mail.munat.com>
    <4B6D69AB.2060508@apache.org>
Date: Sat, 6 Feb 2010 20:33:17 -0800
Subject: Re: [Fwd: Re: Parameters disappear from PUTs]
From: chas@munat.com
To: "Tomcat Users List" <users@tomcat.apache.org>
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

>> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


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