I’m trying to send a JPEG file to a device via a POST command. I’m supposed to send a binary post. I’ve tried using image/jpeg, application/octet-stream, multipart/url-encoded. None give me the result I am expecting. The device should give back an status of 202 if the file transfer is successful. Instead I’m just getting back 200.
The specific Xojo object I’m using is a Xojo.Net.HTTPSocket in an iOS app, but I posted in General as this could apply to a URLConnection as well.
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation. The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed. The representation sent with this response ought to describe the request’s current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
The above is from here, so are you sure the file is not really being accepted?
On the POST do you get back any body content? Perhaps a JSON response with a success false flag and an error message?
Try sending the request via something like Postman or Paw or similar to remove Xojo from the equation and see if it acts the same or different on the device.
A POST request containing a binary upload is likely going to be multipart/form-data. I wrote about doing this with HTTPSocket, but it needs to be updated for recent editions of Xojo.
So I tried setting my content type as multipart/form-data. Still didn’t work.
Do I then need to use your method to re-encode it? That’s going to take a bit of effort as I’m using Xojo.Net.HTTPSocket which is all done with MemoryBlocks. I’ll have to take a look at your class and see if I can translate…
I ended up using the HTTPServer demo app that Xojo provides to take a look at the headers being sent by the Xojo.Net.HTTPSocket. It says everything correct but it does not have the form boundary which looks to be a big part of your code. I can see why a server might not see an image embedded otherwise as the form boundary marks the beginning and end of the data.
Kinda surprising that Xojo doesn’t do it correctly. Well, then again, it is NOT surprising…It is Xojo.
IMHO, it isn’t accurate to say Xojo doesn’t do it correctly. It sends exactly what you tell it to do. The HTTPSocket and HTTPSecureSocket don’t claim to modify the content you pass to be sent. It just calls it the “content”. The fact it even allows you to specify the ContentType is a convenience thing to keep you from also having to add your own ContentType header as well. That’s what I’ve had to do in most other languages.
I think at most you can say that the documentation and example projects could include more examples including a multipart/form-data upload. But it doesn’t say anything wrong, or do anything wrong in my book. Sorry I didn’t think about the multipart thing in my initial responses. Haven’t done one in awhile.
The HTTPSocket (etc.) will automatically encode application/x-www-form-urlencoded forms when using SetFormData instead of SetRequestContent. It’d be trivial to add similar support for encoding multipart/form-data forms.
The fact that they haven’t is highly suspicious IMHO. As if they wanted to avoid direct competition with a certain third party plugin vendor.
Correct. If it sets form content for multi-part forms (and I believe the documents says this), then it should do that. I should not have to build my own header structures simply to post a jpeg image to a website - but I do. Everything else that the HTTPSocket does properly sets up the headers. Why not this?
Highly suspicious? Not unless you can point to feedback requests with many points/followers.
If a third party plugin provides a convenience function for it (and I didn’t realize that was the case), then IMHO the more likely scenario is that vendor is helping make the job easier because Xojo did not provide a function/class method to do so. Not the other way around.
No, the classes have methods to SetFormData, not multipart form data. Those are two different animals in the HTTP world. Though it certainly could be argued it would be helpful if the documentation mentioned that. Regular form data does not use the boundary style delimiters.
You don’t – it does add the ContentType header for you. What it does not do is build out the multipart form CONTENT (as opposed to header).
Semantics to an extent.
Could they also provide a SetMultipartFormData? Clearly that would be possible. But the lack of it, IMHO, is just as likely to be an oversight and lack of feedback requests. (Not that I have checked if there is a feedback request for it.)
Regardless it is not clear in the documentation like a lot of other things. Had Andrew not pointed out that you have to build the form data, I would have no clue why my code was not working. The framework control “should” build out what you need and not leave it up to the user. Why have a high level language at all then? Let’s all program in assembler.
I have posted my modifications to Andrew’s code in another thread so others can more easily do what be and I had to figure out.
That I will grant you. And this is certainly one example where having a Wiki style documentation where users can contribute comments and code snippets would be helpful. Nothing in the docs is wrong per se; just not as helpful as it could be for multipart form usage.
But at least it says a few things. I can’t tell you how many other iOS Framework stuff I’ve looked up with zero or minimal explanation (no example code, etc).