http-client: $bodies in multipart request

11 views
Skip to first unread message

Markus Pilman

unread,
Jan 26, 2010, 8:44:59 AM1/26/10
to expath
Hi,

As seen in the specifiaction, the user has to specify a multipart
request with n parts as follows:

- For every part, he must define a body element - so there are n body
elements in the end.
- If he specifies m bodies with a content, he also must give a
sequence of k:=n-m items in the $bodies parameter of the send-request
function.

I have two comments on that:
1. I think it would be easier to not allow to pass a non-empty
sequence in the $bodies parameter and to have body elements with
children at the same time (this is perhaps only personal taste - but I
can imagine that code, which makes use of this possibility will get
dirty and I don't see any usecases for this feature). So I would
propose that a user can either give a sequence via parameter or define
the content of bodies in the request element - but not both.
2. Which error should be thrown in case that a user gives too many or
too few body-items? err:HC001 doesn't seem to be right here...

Best

Markus

Markus Pilman

unread,
Jan 26, 2010, 8:48:44 AM1/26/10
to expath
About errors more general: what kind of errors should an
implementation throw, when the user messes the parameters up. For
example what should happen, when someone tries:

http:send-request((), ())

Markus

Florent Georges

unread,
Jan 26, 2010, 12:20:04 PM1/26/10
to exp...@googlegroups.com
2010/1/26 Markus Pilman wrote:

> As seen in the specifiaction, the user has to specify a
> multipart request with n parts as follows:

> - For every part, he must define a body element - so there are
> n body elements in the end.

> - If he specifies m bodies with a content, he also must give a
> sequence of k:=n-m items in the $bodies parameter of the
> send-request function.

> I have two comments on that:

> 1. I think it would be easier to not allow to pass a non-empty
> sequence in the $bodies parameter and to have body elements
> with children at the same time (this is perhaps only personal
> taste - but I can imagine that code, which makes use of this
> possibility will get dirty and I don't see any usecases for
> this feature).

Yes, you're maybe right. At least, I think that makes error
reporting more complex (or less efficient, depending on the point
of view).

I do want to be able to set the content directly within
http:body because it has to be simple for simple cases, but I do
want also to be able to pass the content as a separate item
(e.g. a separate document node) to avoid useless copies. But
avoiding both mechanisms at the same time sounds like a good
idea.

What do you think if we required $bodies to be non-empty? So
when the versions without $bodies are used, the http:request
element must contain body contents, and when the version with
$bodies is used, the http:request element must NOT contain those
body contents, they must be provided via $bodies instead.

> 2. Which error should be thrown in case that a user gives too
> many or too few body-items? err:HC001 doesn't seem to be right
> here...

Yes, you're right. I must add another error code in the next
version. Noted there: http://expath.org/wiki/HttpClient, if you
want to follow the todo list.

Regards,

--
Florent Georges
http://www.fgeorges.org/

Markus Pilman

unread,
Jan 26, 2010, 12:27:55 PM1/26/10
to expath
Hi Florent,

>  What do you think if we required $bodies to be non-empty?  So
> when the versions without $bodies are used, the http:request
> element must contain body contents, and when the version with
> $bodies is used, the http:request element must NOT contain those
> body contents, they must be provided via $bodies instead.

I did not think about this possibility, but I think this would be the
best of all!

Markus

> --
> You received this message because you are subscribed to the Google Groups "EXPath" group.
> To post to this group, send email to exp...@googlegroups.com.
> To unsubscribe from this group, send email to expath+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/expath?hl=en.
>
>

Florent Georges

unread,
Jan 26, 2010, 12:36:17 PM1/26/10
to exp...@googlegroups.com
2010/1/26 Markus Pilman wrote:

> About errors more general: what kind of errors should an
> implementation throw, when the user messes the parameters up.
> For example what should happen, when someone tries:

> http:send-request((), ())

I'd say those cases need specific error codes. To be added in
the next version. If you see any other missing error code,
please tell us!

Thanks, regards,

Markus Pilman

unread,
Jan 27, 2010, 1:21:08 AM1/27/10
to expath
Another one would be, if the user does not set href. For example:

http:send-request(<http:request method="GET"/>)

would be statically correct but obviously not a valid request.

Markus

Florent Georges

unread,
Jan 27, 2010, 6:05:09 AM1/27/10
to exp...@googlegroups.com
2010/1/27 Markus Pilman wrote:

> Another one would be, if the user does not set href.

Yep. And when it is not a valid URI:

http://code.google.com/p/expath/issues/detail?id=7

Thanks!

max toro q

unread,
Feb 7, 2010, 10:19:32 PM2/7/10
to exp...@googlegroups.com
I'm not sure this is a good idea. What if the length of $bodies is not
known until runtime? I would have to check count($bodies) and call 2
different overloads of the function, just to avoid the error. I think
usability is more important than ease of implementation.

BTW, this is what I currently use to validate the arguments:

XPathHttpRequest xpathRequest;

int bodiesLength = bodies != null ? bodies.Length : 0;

if (request == null) {

if (string.IsNullOrEmpty(href))
throw new ArgumentException("href cannot be null or
empty if request is null.", "href");

xpathRequest = new XPathHttpRequest {
Method = WebRequestMethods.Http.Get,
Href = new Uri(href)
};

if (bodiesLength > 0)
throw new ArgumentException("Cannot use the bodies
parameter when request is null.", "bodies");

} else {

xpathRequest = new XPathHttpRequest();
xpathRequest.ReadXml(request);

if (string.IsNullOrEmpty(href)) {
if (xpathRequest.Href == null)
throw new ArgumentException("href cannot be null or
empty if request.Href is null.", "href");

} else
xpathRequest.Href = new Uri(href);

if (xpathRequest.Body != null) {

if (bodiesLength > 0) {
if (bodiesLength > 1)
throw new ArgumentException("bodies must have a
single item when request.Body is not null.", "bodies");

xpathRequest.Body.Content = bodies[0];
}

} else if (xpathRequest.Multipart != null) {

if (bodiesLength > 0) {

if (bodiesLength != xpathRequest.Multipart.Items.Count)
throw new ArgumentException("The number of items
in bodies must match the multipart request bodies.", "bodies");

for (int i = 0; i < xpathRequest.Multipart.Items.Count; i++) {
XPathHttpMultipartItem item =
xpathRequest.Multipart.Items[i];

if (item.Body != null)
item.Body.Content = bodies[i];
}
}

} else if (bodiesLength > 0) {
throw new ArgumentException("If bodies is not empty
request.Body or request.Multipart cannot be null.", "request");
}
}

--
Max

2010/1/26 Markus Pilman <tir...@gmail.com>:

Florent Georges

unread,
Feb 8, 2010, 11:08:43 AM2/8/10
to exp...@googlegroups.com
On 8 February 2010 04:19, max toro q wrote:

> I'm not sure this is a good idea. What if the length of $bodies
> is not known until runtime? I would have to check
> count($bodies) and call 2 different overloads of the function,
> just to avoid the error.

Right. So what if we say instead that bodies can be set EITHER
by http:body content OR by $bodies?

Regards,

--
Florent Georges
http://www.fgeorges.org/

[1]http://code.google.com/p/expath/issues/detail?id=5

max toro q

unread,
Feb 8, 2010, 8:55:55 PM2/8/10
to exp...@googlegroups.com
I would like $bodies to override the content in <http:body>, so you
could set them on both places but $bodies wins.
--
Max

2010/2/8 Florent Georges <fgeo...@gmail.com>:

Florent Georges

unread,
Feb 9, 2010, 8:13:09 AM2/9/10
to exp...@googlegroups.com
On 9 February 2010 02:55, max toro q wrote:

> 2010/2/8 Florent Georges wrote:
>> On 8 February 2010 04:19, max toro q wrote:

Hi,

>>> I'm not sure this is a good idea. What if the length of
>>> $bodies is not known until runtime? I would have to check
>>> count($bodies) and call 2 different overloads of the
>>> function, just to avoid the error.

>> Right. So what if we say instead that bodies can be set
>> EITHER by http:body content OR by $bodies?

> I would like $bodies to override the content in <http:body>, so


> you could set them on both places but $bodies wins.

That's what would be nice, sure. But that does not cope well
with multipart, really. How do you map the $bodies to the
corresponding parts in http:request when, say, you want to
override the second and third parts:

<http:multipart ...>
<http:body ...>Part 1</http:body>
<http:body ...>Part 2</http:body>
<http:body ...>Part 3</http:body>
<http:body ...>Part 4</http:body>
</http:multipart>

What sequence could you set $bodies to override parts 2 & 3?

If you have one single part, that's possible. And that's
actually achieved by the proposed change (aka "if $bodies is not
the empty sequence, then it must have the content for every
existing http:body"). In the specific case of 1 part, then you
have either 1 item or the empty sequence, so $bodies overrides
http:body content if present.

But with multipart, I don't want to defined too complex mapping
rules. When we'll have first-class function items, then we could
define more sofisticated mechanism. But for now I cannot think
of something not too much complex. But I maybe missed a simple
solution?

max toro q

unread,
Feb 9, 2010, 10:42:18 PM2/9/10
to exp...@googlegroups.com
We can say that when $bodies is not empty then it must contain the
same number of items as <http:multipart>, or a single item if
<http:body> is used.

We don't need to make $bodies required, i.e. an empty-sequence is
accepted and ignored.
--
Max

2010/2/9 Florent Georges <fgeo...@gmail.com>:

Florent Georges

unread,
Feb 9, 2010, 11:09:58 PM2/9/10
to exp...@googlegroups.com
On 10 February 2010 04:42, max toro q wrote:

> We can say that when $bodies is not empty then it must contain the
> same number of items as <http:multipart>, or a single item if
> <http:body> is used.

> We don't need to make $bodies required, i.e. an empty-sequence is
> accepted and ignored.

Yes, I think we agree. Just to be sure:

IF $bodies is empty
content is set from the http:body elements
ELSE
count($bodies) must be = to count($request//http:body)
and the content is set from $bodies
($bodies[1] for the first http:body, and so on...)

Is that what you have in mind?

max toro q

unread,
Feb 10, 2010, 8:15:24 AM2/10/10
to exp...@googlegroups.com
Yes, exactly that.
--
Max

2010/2/10 Florent Georges <fgeo...@gmail.com>:

Reply all
Reply to author
Forward
0 new messages