http-client: $bodies in multipart request
Markus Pilman
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
implementation throw, when the user messes the parameters up. For
example what should happen, when someone tries:
http:send-request((), ())
Markus
Florent Georges
> 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
> 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
> 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
http:send-request(<http:request method="GET"/>)
would be statically correct but obviously not a valid request.
Markus
Florent Georges
> 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
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
> 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/
max toro q
could set them on both places but $bodies wins.
--
Max
2010/2/8 Florent Georges <fgeo...@gmail.com>:
Florent Georges
> 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
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
> 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?