according to "
http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/urlfetch/HTTPRequest.html":
------------------------------------------------------------------------------------------------------------------------------------------------------------
setPayload
public void setPayload(byte[] payload)
Sets the payload for this request. This method should not be
called for certain HTTP methods (e.g. GET).
------------------------------------------------------------------------------------------------------------------------------------------------------------
I know it seems logical that GET's should only send a url with QS
(Query String) params to qualify the get, but if I have a complex
subscription/highly-directly query, I would prefer to send all the
parameters as payload/XML.
from RFC2616:
------------------------------------------------------------------------------------------------------------------------------------------
The HTTP protocol (i.e.RFC2616) does not REQUIRE that GET's not
contain a paylod.
Why would the library enforce such a restriction?
4 HTTP Message
4.1 Message Types
HTTP messages consist of requests from client to server and
responses
from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the
generic
message format of RFC 822 [9] for transferring entities (the
payload
of the message). Both types of message consist of a start-line,
zero
or more header fields (also known as "headers"), an empty line
(i.e.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words,
if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by
the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with
an
extra CRLF.
------------------------------------------------------------------------------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
