fix. Stay tuned
Cheers
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 04:29
To: Commons HttpClient Project
Subject: Re: Post Method
There seems to be quite a bit of discussion regarding this question but
not too much that s
In theory I agree, but I see a lot of uses of the O'Reilly multipart
stuff,
which expects "multipart/form-data" (see:
http://www.servlets.com/cos/javadoc/com/oreilly/servlet/multipart/
MultipartParser.html)
Yes, please take a look at MultipartPostMethod.
I had a specific problem with the and x-
the encoding myself when adding the name/values.
Paul Philion
[EMAIL PROTECTED]
- Original Message -
From: "Michael Becke" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Tuesday, June 10, 2003 10:29 PM
Subject: Re: Post Me
There seems to be quite a bit of discussion regarding this question but
not too much that seems ultimately definitive. This one seems to be
the best:
http://groups.google.com/groups?oi=djq&selm=an_537840002
Essentially the author says that form encoding and URI encoding are two
unrelated thin
Yes, this can be accomplished with the MultipartPostMethod. But as you
mentioned I think this is meant for posting larger, perhaps binary,
content in combination with standard text parameters.
Mike
On Tuesday, June 10, 2003, at 01:46 PM, Laura Werner wrote:
Kalnichevski, Oleg wrote:
must the
Kalnichevski, Oleg wrote:
must the body of a post request be encoded as a URL Query?
Yes, it must, when the post body content is specified as a set of name/value pairs.
I think you're also allowed to use the multipart/form-data MIME type
rather than application/x-url-encoded (or whatever i
Michael Becke wrote:
I think there may be a bug here as well. According to the spec, space
characters should be represented as '+' but URIUtil is encoding them as
'%20'. I think the resevered character set is perhaps also incorrect.
According to rfc 1738 ";", "/", "?", ":", "@", "=" and "&" ar
I think there may be a bug here as well. According to the spec, space
characters should be represented as '+' but URIUtil is encoding them as
'%20'. I think the resevered character set is perhaps also incorrect.
According to rfc 1738 ";", "/", "?", ":", "@", "=" and "&" are the
reserved chars
> must the body of a post request be encoded as a URL Query?
Yes, it must, when the post body content is specified as a set of name/value pairs.
For more details you may refer to
http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1
One can still provide a raw post body and a custom con
Manuel Castro Paliza wrote:
From NameValuePair to NameValuePair?¿?.
Sorry by my lack of java knowledge but I don't understand this conversion,
is something about memory?.
no. we generally call it bad design, or spaghetti code.
---
Patch applied.
Thomas, please let me know if that fixes the problem for you
Cheers
Oleg
PS: my apologies for mixing up your first and last name
On Mon, 2003-02-03 at 19:41, [EMAIL PROTECTED] wrote:
> All right. We did talk about different things. Now I see the problem. Whoever
>initially progr
All right. We did talk about different things. Now I see the problem. Whoever
initially programmed PostMethod did not take content encoding into consideration when
performing URL encoding, and I blundered by failing to properly audit that bit of
code.
I'll fix it right away
Thanks for pinning
Let me make some definitions to ensure we are talking about the same
thing. There are two encodings envolved:
Enc 1 Enc 2
[unicode string] --> URL encoded form > byte[]
"ö" URLEnc w/ UTF-8 %C3%B6 ASCII 0x25, 0x43 ..
Odi,
GET is an entirely different ball game. RFC is quite explicit about it: it's US-ASCII
all over the place, except for request/response body. That's why it takes URL-encoding
in the very first place in order to comply with the spec. Only request/response body
may be encoded with a different e
[EMAIL PROTECTED] wrote:
RFC 2616 does not seem to say much. So, I assume that the default
scheme applies: whatever charset is specified in "Content-Type"
header. If charset is not explicitly set, ISO-8859-1 is used per
default.
I guess this is the way to go for POST. But what about GET? There i
RFC 2616 does not seem to say much. So, I assume that the default scheme applies:
whatever charset is specified in "Content-Type" header. If charset is not explicitly
set, ISO-8859-1 is used per default.
Do you see it differently?
Cheers
Oleg
-
[EMAIL PROTECTED] wrote:
Aha, it just hit me. Post parameters are url encoded, so all umlauts
get escaped. If you send as a parameter value something like that:
"Grüezi, Herr Thomas"
You gonna get this:
"Gr%C3%BCezi%2C%20Herr%20Thomas"
I hope you are aware of that
Oleg
And which encoding s
Aha, it just hit me. Post parameters are url encoded, so all umlauts get escaped. If
you send as a parameter value something like that:
"Grüezi, Herr Thomas"
You gonna get this:
"Gr%C3%BCezi%2C%20Herr%20Thomas"
I hope you are aware of that
Oleg
--
as the same
>(wrong encoding)!
>Thomas
>
>-Ursprüngliche Nachricht-
>Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]]
>Gesendet: Mittwoch, 15. Januar 2003 10:22
>An: Commons HttpClient Project
>Betreff: RE: POST method - Default content encoding
>
>
>Thomas
&
19 matches
Mail list logo
