Excerpts from Bill Moseley's message of Sat Jan 23 19:45:28 -0500 2010:
With a jpeg I assume the content type would be form-data (that included an
upload in the form) where the file ends up in $req->uploads, not as a
request parameter.
On Sat, Jan 23, 2010 at 1:40 PM, J. Shirley wrote:
If I assume that decoding is synonymous with de-serialization, it
makes more sense. At first thought, I just don't think they're that
similar, though. Maybe in implementations (comparing JSON to HTTP
POST parameters) it is, but in the case of HTTP::Body decoding a
mime64-encoded JPEG, it isn't at all.
If I assume that decoding is synonymous with de-serialization, it
makes more sense. At first thought, I just don't think they're that
similar, though. Maybe in implementations (comparing JSON to HTTP
POST parameters) it is, but in the case of HTTP::Body decoding a
mime64-encoded JPEG, it isn't at all.
With a jpeg I assume the content type would be form-data (that included an
upload in the form) where the file ends up in $req->uploads, not as a
request parameter.
anything about a form or even a web browser. It's perfectly reasonable,
especially in the context of REST APIs, to talk about non-form-based request
bodies. (I've written actions that accepted PUT requests with a content-type
of application/vnd.ms-excel, for example.)
hdp.
