On 9 February 2010 15:26, Christopher Schultz
wrote:
> I've learned a lot from
> reading and participating in many discussions on this list, and I think
> you probably will, too, if you stick around.
I think many of us have learned a lot. Sometimes it's been technical,
sometimes on how to deal w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chas,
On 2/8/2010 10:24 PM, c...@munat.com wrote:
>> I'm unaware of any uses of PUT that automatically parse the request body
>> on behalf of the user's code. Instead, the user's code is typically
>> expected to handle the entire request body. Apache
Chris,
> I realize that this issue has been essentially solved, but it's probably
> worth it to continue the discussion.
Happy to continue if it's productive.
> I routinely use Firefox and LiveHTTPHeaders: that add-on definitely does
> indicate what is form data for a POST request, but I've neve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chas,
I realize that this issue has been essentially solved, but it's probably
worth it to continue the discussion.
On 2/8/2010 1:51 PM, c...@munat.com wrote:
> That was a response to smoke and hand-waving in another post and certainly
> nothing that
I posted it exactly as it came to me.
> On Saturday 06 February 2010 03:27:23 c...@munat.com wrote:
>> Are you serious?
>
> [...]
>
>> I'm certain you're not suggesting that browsers be forced to insert a
>> name
>> before the parameter string in every POST request.
> [...]
>> What does *any* of t
>> We were discussing RFC 2616. Entity-headers and entity-body are terms
>> directly from the RFC and are defined therein. No, they are not the same
>> as HTTP headers, though they are contained in the HTTP headers:
>
> To-MAY-to, to-MAH-to.
That was a response to smoke and hand-waving in another
On Saturday 06 February 2010 03:27:23 c...@munat.com wrote:
> Are you serious?
[...]
> I'm certain you're not suggesting that browsers be forced to insert a name
> before the parameter string in every POST request.
[...]
> What does *any* of this have to do with a simple
> post to the list explai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 2/7/2010 5:28 AM, Mark Thomas wrote:
> I'll add an enhancement request to Tomcat 7. Because this is a grey area
> other folks using Tomcat may be expecting the data in the request body
> and changing that would break things for them. It will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chas,
On 2/5/2010 7:13 PM, c...@munat.com wrote:
> We were discussing RFC 2616. Entity-headers and entity-body are terms
> directly from the RFC and are defined therein. No, they are not the same
> as HTTP headers, though they are contained in the HTT
On 07/02/2010 21:27, c...@munat.com wrote:
>> I'll add an enhancement request to Tomcat 7. Because this is a grey area
>> other folks using Tomcat may be expecting the data in the request body
>> and changing that would break things for them. It will certainly have to
>> be optional. As to which sh
> Just to to clarify this point, the entity in the example wireshark trace
> you provided is in the request body, not the headers.
I wasn't aware that I had provided a Wireshark trace, but that's good to
know. (Wireshark would not install without a fight on my Mac, so my
brother ran the trace on h
On 07/02/2010 05:03, c...@munat.com wrote:
>> I have just re-read section 9.6 of RFC2616. My understanding of PUT was
>> (and still is) that the entity body provided is used to create/replace
>> the entity at the provided URI. This is how Tomcat handles PUT requests
>> (it enabled) in the DefaultSe
> I have just re-read section 9.6 of RFC2616. My understanding of PUT was
> (and still is) that the entity body provided is used to create/replace
> the entity at the provided URI. This is how Tomcat handles PUT requests
> (it enabled) in the DefaultServlet.
I agree that this is the intent of the
>> 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 pro
On 06/02/2010 03:02, c...@munat.com wrote:
> I believe that via a post on another list I have discovered the source of
> the trouble:
>
> According to the servlet specification...
>
> The following are the conditions that must be met before post form
> data will be populated to the parameter set:
On 06/02/2010 02:27, c...@munat.com wrote:
> Are you serious?
>
> I don't generate request headers. The browser does. And they do so
> identically whether the HTTP method is PUT or POST and whether it's an
> XMLHttpRequest or not. And I suspect that they've been doing so pretty
> much since Marc A
I believe that via a post on another list I have discovered the source of
the trouble:
According to the servlet specification...
The following are the conditions that must be met before post form
data will be populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP
Are you serious?
I don't generate request headers. The browser does. And they do so
identically whether the HTTP method is PUT or POST and whether it's an
XMLHttpRequest or not. And I suspect that they've been doing so pretty
much since Marc Andreesen was still in Champaign-Urbana and Mosaic was
s
On Fri, Feb 5, 2010 at 4:13 PM, wrote:
> PUT /json/members/1b35d32f-714d-4393-b8c2-b4805e0c7a13 HTTP/1.1
> Host: localhost:12344
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
> Accept: text/html,application/xhtml+xml,application/x
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
RE
> Could you please be clear when you say "entity headers": do you mean
> HTTP headers? I have a Tomcat 6.0.20 install right in front of me that
> definitely does allow the servlet (in my case, a simple JSP that dumps
> requests) to read the HTTP headers. HTTP GET parameters are also
> correctly pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chas,
On 2/5/2010 2:45 PM, 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.
Could you please be clear when you say "entity h
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
> From: c...@munat.com [mailto:c...@munat.com]
> Subject: RE: [Fwd: Re: Parameters disappear from PUTs]
>
> Read the entire section before you comment!
Sorry, I hadn't done that. As I said before, I believe your interpretation is
correct.
- Chuck
THIS COMMUNICATION MAY CON
*quite clear* on the
difference between POST and PUT -- Roy Fielding, et al, did an excellent
job of it.
Can we, finally, let it rest there? (Pun intended.)
Chas.
>> From: c...@munat.com [mailto:c...@munat.com]
>> Subject: Re: [Fwd: Re: Parameters disappear from PUTs]
>>
>>
> From: c...@munat.com [mailto:c...@munat.com]
> Subject: Re: [Fwd: Re: Parameters disappear from PUTs]
>
> RFC 2616 is quite clear on this topic, IMO.
Maybe not.
> The POST method is used "to request that the origin server accept the
> *entity* enclosed in the request
es may have felt justified in providing such handling.
> The point I am trying to make is that if you create an application which
> depends on parameters being processed in a PUT request, you may well
> create an application which is not portable to all servlet engines or
> HTTP servers. B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chas,
On 2/3/2010 11:40 PM, c...@munat.com wrote:
> I am submitting forms to a restful interface using an HTTP PUT with the
> params in the header of the PUT. I believe that's normal, and it works
> just fine on Jetty. The params are definitely sent.
inal Message ----
Subject: Re: Parameters disappear from PUTs
Date: Thu, 4 Feb 2010 05:03:10 -0800
From: c...@munat.com
To: a...@ice-sa.com
References: <2e9812dbea1d2cdeedb703759e39e602.squir...@mail.munat.com>
<4b6ac1cc.5020...@ice-sa.com>
By golly, you're right! Aren'
c...@munat.com wrote:
I am submitting forms to a restful interface using an HTTP PUT with the
params in the header of the PUT. I believe that's normal, and it works
just fine on Jetty. The params are definitely sent.
When I load my app into Tomcat 6 (Ubuntu), the form submission works
perfectly
manager being enabled by default.
>>
>> Just my two cents . . .
>>
>> /mde/
>>
>> --- On Wed, 2/3/10, c...@munat.com wrote:
>>
>>> From: c...@munat.com
>>> Subject: RE: Parameters disappear from PUTs
>>> To: "Tomcat Users List&qu
ugs database, there are many instances
> of people complaining about the security manager being enabled by default.
>
> Just my two cents . . .
>
> /mde/
>
> --- On Wed, 2/3/10, c...@munat.com wrote:
>
>> From: c...@munat.com
>> Subject: RE: Parameters disappear
om: c...@munat.com
> Subject: RE: Parameters disappear from PUTs
> To: "Tomcat Users List"
> Date: Wednesday, February 3, 2010, 10:43 PM
> OK, turns out my brother has
> wireshark installed. We ran it, and the
> packets are definitely getting to the server with the PUT
> p
aptop, but macports is still at 20,
too. Guess I'll have to do it the hard way.
>>> From: c...@munat.com [mailto:c...@munat.com]
>>> Subject: Parameters disappear from PUTs
>>>
>>> When I load my app into Tomcat 6 (Ubuntu), the form submission works
>>&g
>> From: c...@munat.com [mailto:c...@munat.com]
>> Subject: Parameters disappear from PUTs
>>
>> When I load my app into Tomcat 6 (Ubuntu), the form submission works
>> perfectly if I use a POST: the params are definitely received. If I
>> use a PUT, it works,
> From: c...@munat.com [mailto:c...@munat.com]
> Subject: Parameters disappear from PUTs
>
> When I load my app into Tomcat 6 (Ubuntu), the form submission works
> perfectly if I use a POST: the params are definitely received. If I
> use a PUT, it works, but the parameters are m
I am submitting forms to a restful interface using an HTTP PUT with the
params in the header of the PUT. I believe that's normal, and it works
just fine on Jetty. The params are definitely sent.
When I load my app into Tomcat 6 (Ubuntu), the form submission works
perfectly if I use a POST: the par
37 matches
Mail list logo
