Using POST to send bitmap image with Java

[Dexter]

In one of my Graphing programs written in Java, I am trying to send a
graphics image (.bmp) to HttpModule on the same server that hosts the
graphing applet.

I found some code on internet that helped me post text data to the
module.

Can someone suggest how I may post the graphics image binary data
using POST method

 

[Dave Miller]

In one of my Graphing programs written in Java, I am trying to send a
graphics image (.bmp) to HttpModule on the same server that hosts the
graphing applet.

I found some code on internet that helped me post text data to the
module.

Can someone suggest how I may post the graphics image binary data
using POST method

URL url = new URL("http://www.your-server.com");
HttpURLConnection connection = (HttpURLConnection)url.openConnection();
connection.setRequestMethod("POST");
connection.setDoInput(true);
connection.setDoOutput(true);
connection.connect();
DataOutputStream out =
new DataOutputStream(connection.getOutputStream());
// use one of write methods of out
out.flush();
out.close();

 

[Dave Miller]

I'm actually in the process of doing this right now. I'm going to be
posting the image to a URL that is a PHP script. When I was looking at
this I thought that this really made more sense to use a PUT method to
post the image, but the guy working on the PHP side insisted on using a
POST method.

Is there a reason that POST would be selected over PUT for this
application? Are there reasons to go with PUT here?

Thanks.

If you are sending other data with the request(i.e. a caption for the
picture), POST is the designed protocol. If you are just sending a file
to be saved to the server use PUT or POST. In other words POST is
designed to put but PUT isn't meant to post. It's a distinction without
a difference from your side of the code - if the PHP guy want's POST ...

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

 

[John B. Matthews]

I'm actually in the process of doing this right now. I'm going to be
posting the image to a URL that is a PHP script. When I was looking at
this I thought that this really made more sense to use a PUT method to
post the image, but the guy working on the PHP side insisted on using a
POST method.

Is there a reason that POST would be selected over PUT for this
application? Are there reasons to go with PUT here?

<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>:

"The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a POST
request identifies the resource that will handle the enclosed entity...
In contrast, the URI in a PUT request identifies the entity enclosed
with the request..."

Since you're "posting the image to a URL," I think you answered your own
question

John

 

[Arne Vajhøj]

I'm actually in the process of doing this right now. I'm going to be
posting the image to a URL that is a PHP script. When I was looking at
this I thought that this really made more sense to use a PUT method to
post the image, but the guy working on the PHP side insisted on using a
POST method.

Is there a reason that POST would be selected over PUT for this
application? Are there reasons to go with PUT here?

PUT file

uploads a file to specified name via a builtin mechanism
in the web server.

POST uploadscript

send a file to the specified script that can save it as
a file or in a database or whatever.

Not all web servers support or is configured to allow PUT,
while POST is supported by all web servers.

With POST you can also use form based multi part where you
can upload additional info about the file and multiple files
in a single POST.

Arne

 

[Arne Vajhøj]

DataOutputStream out =
new DataOutputStream(connection.getOutputStream());
// use one of write methods of out

If the only type send is byte/byte[] then wrapping
in DataOutputStream should not be necesarry.

Arne

 

[Arne Vajhøj]

Maybe I should have stated that differently. I'm really just uploading
an image to a server. There isn't any metadata or anything. Just an
image.

Unless your server is configured to support PUT and configured
to PUT files where you want them, then POST is still better.

Arne

 

[Dave Miller]

PUT file

uploads a file to specified name via a builtin mechanism
in the web server.

Apache does not use PUT except via mod_dav (WebDAV). A handler must be
built for everything but GET.

POST uploadscript

send a file to the specified script that can save it as
a file or in a database or whatever.

Not all web servers support or is configured to allow PUT,
while POST is supported by all web servers.

While the above statement is true, it is no longer common to disable PUT
and DELETE server wide because WebDAV requires both. It was never common
to limit POST but the limit has always been available on Apache.

With POST you can also use form based multi part where you
can upload additional info about the file and multiple files
in a single POST.

POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.

The PUT method requests that the enclosed entity be stored under the
supplied Request-URI.


The reason why the PHP guy wants a POST may be the following. When you
send a PUT, the servers config has to tell it what handler to use - the
URI is the target file of the PUT. With a POST, the URI is the handler
- no modification of the config needed.

 

[s0suk3]

Not all web servers support or is configured to allow PUT,
while POST is supported by all web servers.

Not necessarily. An HTTP compliant server is only required to
implement GET and HEAD; all other methods are optional.

 

[Kevin McMurtrie]

I'm actually in the process of doing this right now. I'm going to be
posting the image to a URL that is a PHP script. When I was looking at
this I thought that this really made more sense to use a PUT method to
post the image, but the guy working on the PHP side insisted on using a
POST method.

Is there a reason that POST would be selected over PUT for this
application? Are there reasons to go with PUT here?

Thanks.

PUT is simple, efficient, and robust for transferring a single file.
POST is inefficient and less robust (stupid MIME format) but it can also
support complex types of data.

The server-side developer has a say in this. POST is easier to use in a
high-level framework. PUT is easier to use in a low-level framework.

 

[Arne Vajhøj]

While the above statement is true, it is no longer common to disable PUT
and DELETE server wide because WebDAV requires both.

Not everyone uses WebDAV.

Arne

 

[Arne Vajhøj]

Not necessarily. An HTTP compliant server is only required to
implement GET and HEAD; all other methods are optional.

That is what the HTTP 1.1 spec says.

But POST is present in all major web servers.

Apache, IIS, Tomcat etc..

Arne

 

[Dave Miller]

Example from the real world?

Apache - POST, DELETE and PUT all require handlers. The below is an old
article but, AFAIK, the server hasn't changed as of 2.2 (If you know
different, please post reference - I'd like to know how to implement.)

http://www.apacheweek.com/features/put

 

[Dave Miller]

That is what the HTTP 1.1 spec says.

But POST is present in all major web servers.

Apache, IIS, Tomcat etc..

Arne

I'm confused as to what you mean by "present". I can't speak to IIS - I
wouldn't know one if you dropped it on my foot - but Apache and Tomcat
only handle POST if you write a handler. If you know differently, please
post the reference - I've spent a fair amount of time in both sets of
docs and I've never seen "how to (natively)" in either.

 

[Dave Miller]

DataOutputStream out =
new DataOutputStream(connection.getOutputStream());
// use one of write methods of out

If the only type send is byte/byte[] then wrapping
in DataOutputStream should not be necesarry.

Arne

Good point - the code was copy and paste from a bit that needed the
additional write methods of DataOS.

 

[Arne Vajhøj]

I'm confused as to what you mean by "present". I can't speak to IIS - I
wouldn't know one if you dropped it on my foot - but Apache and Tomcat
only handle POST if you write a handler. If you know differently, please
post the reference - I've spent a fair amount of time in both sets of
docs and I've never seen "how to (natively)" in either.

I think we have a terminology problem here.

Both Tomcat and Apache support POST out of the box in the
sense that they accept the request and pass it on.

But you need to post to something. And even though you can
technically post to a HTML page, then there are not much
point.

It only makes sense if the post is to some code: servlet,
PHP, CGI script whatever.

Arne

 

[Arne Vajhøj]

Apache - POST, DELETE and PUT all require handlers. The below is an old
article but, AFAIK, the server hasn't changed as of 2.2 (If you know
different, please post reference - I'd like to know how to implement.)

http://www.apacheweek.com/features/put

That article is pretty bad.

#In fact, Apache handles PUT exactly like it handles the POST method.
#That is, it supports it, but in order for it to do anything useful you
#need to supply a suitable CGI program. This is on contrast to the GET
#method, which Apache supports internally by sending back files or SSI
#documents.

is not a very accurate description.

GET and POST are identical:
* the browser specify what script to run
* no special configuration of method is needed
(the only difference is that GET is good for both static and
dynamic resources while POST is only good for dynamic
resources)

PUT requires special configuration in the server and the
script is specified there - not by the browser.

Arne

 

[Dave Miller]

I think we have a terminology problem here.

Both Tomcat and Apache support POST out of the box in the
sense that they accept the request and pass it on.

But you need to post to something. And even though you can
technically post to a HTML page, then there are not much
point.

It only makes sense if the post is to some code: servlet,
PHP, CGI script whatever.

Arne

You're right, we are saying the same thing - they won't reject a POST
but without a handler they won't do anything with it either. In the case
of Apache, it seems to get treated as a GET. (Just for sport I just
tried to POST to an html page and got the page itself returned.)

 

[Dave Miller]

So Apache *does* implement POST. It's the non-existent script that is
failing, not Apache Web Server. Adding that script is no change to Apache.

Leaving open the question - are there any real-world web servers that do
not implement POST?

Not to go Bill Clinton here, but it depends on what your definition of
"implement" is.

Unless set to reject them, all 1.1 http servers will not reject any 1.1
method (POST, PUT, DELETE, etc.) within the request. The question is
"what next".

In the case of GET, it returns the content of the target page if it
exists. In the case of all other methods, the server passes the request
onto the designated handler, treats the request as a GET or returns a
not found error.

Long story short, a successful GET request can be made using only the
web server. For all other methods, POST and PUT included, a request can
not succeed unless a handler has been added to the web server. If the
handler properly exists, the web server passes the request and response
between the handler and client.

If the last two sentences above meets your definition of "implement",
the answer to your original question is "all 1.1 http servers implement
all 1.1 methods POST and PUT included".

 

[Arne Vajhøj]

Not to go Bill Clinton here, but it depends on what your definition of
"implement" is.

Unless set to reject them, all 1.1 http servers will not reject any 1.1
method (POST, PUT, DELETE, etc.) within the request. The question is
"what next".

In the case of GET, it returns the content of the target page if it
exists. In the case of all other methods, the server passes the request
onto the designated handler, treats the request as a GET or returns a
not found error.

Long story short, a successful GET request can be made using only the
web server. For all other methods, POST and PUT included, a request can
not succeed unless a handler has been added to the web server. If the
handler properly exists, the web server passes the request and response
between the handler and client.

If the last two sentences above meets your definition of "implement",
the answer to your original question is "all 1.1 http servers implement
all 1.1 methods POST and PUT included".

Not quite accurate.

For a standard "out-of-the-box" Apache:
GET and POST both work
PUT gives a status code 405 "Method Not Allowed"

You need a dynamic resource to do something useful with the POST
request.

Arne