M
Mike
[BTW, is there no J2ME group?]
I have questions regarding the J2ME/MIDP connection manager HTTPConnection
and HTTP 1.0 vs. 1.1 -
although the question is probably not J2ME-specific. (I'm using MIDP 1.0.)
I have a working moble client/server application, and as setting up and
tearing down a socket over the mobile network is something I can see I'd
like to keep to a minimum, I'd like to know how to best take advantage of
HTTP 1.1. (Currently my back end is MS IIS.)
I have noticed the following behavior:
- The HTTP request seems to be actaully sent when I try and open the
inputStream on
the HTTP connection. (Although other calls like GetResponse could do so as
well I assume.)
What returns at this point is a 1.1 200 OK, although the HTTP monitor
shows that no body/content has been reterieved yet.
- When I try and read from the input stream, the monitor shows content. So
it looks like the socket stays open and the read happens on-demand.
- After I process my request, I close the input stream and http connection
and start over.
Questions:
(a) Can I keep my http connection open so the same socket is used for
subsequent requests? (If it happens to be able to stay open on the phone, of
course.)
Or will HTTPConnection re-use a socket underneath the hood for the
same server even when the HTTPConnection object is closed by doing some
smart connection caching?
(b) Although reading on-demand has advantages, I know I always want my
content (no need to check header dates first, etc.) so I'd like the body to
be
transferred with the HTTP header -- reducing the # of packets and latency
seems especially beneficial on the phone. So perhaps I should be using 1.0?
If the answer to question (a) is true, can I still use 1.1 but tell it to
send the content ASAP with the header and still get socket re-use?
Any points on optimal HTTPConnection use, optimal headers/settting, etc.,
for mobile HTTP would be appreciated.
thanks,
mike
I have questions regarding the J2ME/MIDP connection manager HTTPConnection
and HTTP 1.0 vs. 1.1 -
although the question is probably not J2ME-specific. (I'm using MIDP 1.0.)
I have a working moble client/server application, and as setting up and
tearing down a socket over the mobile network is something I can see I'd
like to keep to a minimum, I'd like to know how to best take advantage of
HTTP 1.1. (Currently my back end is MS IIS.)
I have noticed the following behavior:
- The HTTP request seems to be actaully sent when I try and open the
inputStream on
the HTTP connection. (Although other calls like GetResponse could do so as
well I assume.)
What returns at this point is a 1.1 200 OK, although the HTTP monitor
shows that no body/content has been reterieved yet.
- When I try and read from the input stream, the monitor shows content. So
it looks like the socket stays open and the read happens on-demand.
- After I process my request, I close the input stream and http connection
and start over.
Questions:
(a) Can I keep my http connection open so the same socket is used for
subsequent requests? (If it happens to be able to stay open on the phone, of
course.)
Or will HTTPConnection re-use a socket underneath the hood for the
same server even when the HTTPConnection object is closed by doing some
smart connection caching?
(b) Although reading on-demand has advantages, I know I always want my
content (no need to check header dates first, etc.) so I'd like the body to
be
transferred with the HTTP header -- reducing the # of packets and latency
seems especially beneficial on the phone. So perhaps I should be using 1.0?
If the answer to question (a) is true, can I still use 1.1 but tell it to
send the content ASAP with the header and still get socket re-use?
Any points on optimal HTTPConnection use, optimal headers/settting, etc.,
for mobile HTTP would be appreciated.
thanks,
mike