Skip to main content

Chunked Transfer Encoding

14 replies [Last post]
Anonymous

Does somebody was able to get ride of the famous "chunked encoding issue"?

the problem raise when you try to send more than 2048 bytes of data
through HTTP, it appears than J2ME then use chunked mode encoding.
But many of the server does not understand chunked encoding. Some does
(for instance, in mobup I was able to upload pictures to Flickr without
problem), but on my apache server, I've got some errors when trying to
access to a php page with a "chunked post"

Logs show: "chunked Transfer-Encoding forbidden" in apache

A search on the web shows that I am not the only one to have such issue,
but did not found any solution on this yet. Any idea?

Thanks for any suggestion/help

--
Thomas Landspurg
http://blog.landspurg.net

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joe Bowbeer

On 12/10/06, Thomas Landspurg
wrote:
>
> The fact is that it happens locally too, between the WTK and my Apache
> running on the same host! So with this configuration, I am quite sure that
> there is no gateway in between!
> So I am quite sure it's linked to my apache configuration......It's
> Apache/2.0.59 (Win32) with PHP/5.2.0 .
>

That's great. I was going to ask for carrier and APN info, too (in
addition to sample code), but if you've reproduced the same error
locally, then you're much farther along.

I'm still interested in the seeing the relevant client code. Mostly
to check that the output stream is not being flushed before it is
closed, and that you're writing directly to the output stream and not
through some unknown middleman, such as a web service layer.

Putting that aside for the moment,

Can you reproduce the same error if you enable network monitoring in the WTK?
Preferences / Monitor / Enable Network Monitoring

If so, I think a snippet from the monitor log would be interesting.

If that doesn't help, my next step would be to insert a Tomcat proxy
servlet between the MIDlet and the offending server. That may solve
the problem. If not, you'll have a great tool in place for continued
debugging :-)

--Joe

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gary Adams

Thomas Landspurg wrote:
> Hello Gary,
>
>
> Tha fact is that it happens locally too, between the WTK and my Apache
> running on the same host! So with this configuration, I am quite shure
> that there is no gateway in between!
> So I am quite sure it's linked to my apache configuration......It's
> Apache/2.0.59 (Win32) with PHP/5.2.0 .
>
>
> On 12/10/06, *Gary Adams* > > wrote:
>
> What version of apache server is being used? Since Version 2.0,
> I believe persistent connections have been the default behavior,
> which is required by the HTTP 1.1 protocol.
>
> Just because an application sets Content-Length, does not mean the
> implementation can trust that value. It also may not have large
> enough buffers to write large buffers. In which case the application
> large data transfer may be broken into smaller chunks for transmission.
>
> You might also be suffering from proxy servers that may be chunking
> the stream as well. Your best bet is to find out which component
> in the chain (http client, proxy server, or http server) is failing
> to handle the chunked transfer encoding. My guess is you have an
> HTTP 1.0 component somewhere in the chain. This is one reason some
> implementations will use "tunneling" to get packets through an
> HTTP 1.0 proxy between an HTTP 1.1 client and server.
>
> Gary
>
> Thomas Landspurg wrote:
>
> > Hello,
> >
> > No, I would like to fix it on server side. The client must use
> as much
> > as possible "standard" HTTP implmentations. So doing it by myself
> won't
> > work on handset not supporting sockets.
> > I've tried to set up content length on the request, but it
> always fall
> > back in chunked mode....
> >
> > So on the server side: I use apache with php. I did not see any
> option
> > for this?
> >
> > Also, I am open to any other suggestion, like a proxy server, to
> > change the chunked request into an unchunked request.....
> >
> > On 12/9/06, *Gary Adams* < Gary.Adams@sun.com
>
> > >> wrote:
> >
> > Chunking will also be used if an implementation has limited
> buffering
> > capabilities, and a full request can not be counted. e.g. to
> use HTTP
> > 1.1 persistent connections either a Content-Length for the entire
> > transaction must be provided, or individual chunks with
> intermediate
> > chunk sizes must be provided.
> >
> > Joe Bowbeer wrote:
> >
> >
> >
> > --
> > Thomas Landspurg
> > http://blog.landspurg.net
> >
> ===========================================================================
>
> > To unsubscribe, send email to listserv@java.sun.com
> and include in the
> > body of the message "signoff KVM-INTEREST". For general help,
> send email
> > to listserv@java.sun.com and
> include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com
> and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in
> the body of the message "help".
>
>
>
>
> --
> Thomas Landspurg
> http://blog.landspurg.net
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email
> to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Frank Gaebler

Hi Joe,

> Clarification: The problem is really on the server side, but
> you want to fix it in the mobile client, right?

Yes. But I wouldn't call it a "fix"; it's more a workaround for
cases where you cannot change it easily on the server side.

> Can you send sample code? It's hard to debug this in the
> abstract, as you know.

Basicallly: open an output-stream on a SocketConnection and write a
string to it like e.g.
"POST /uploadUrl HTTP/1.0\r\n"
+ "Content-Type: multipart/form-data; boundary=ksjfhskjhflsafh\r\n"
+ "Content-Length: 8746\r\n"
+ "Host: www.xyz.com:80\r\n\r\n";
followed by the upload data of length 8746.

> Are you sure you're not flushing the output stream before
> you've finished writing the data? I think this is the usual
> way that chunking gets triggered unintentionally.
>
> Are you sure you're setting content-length?

I tried all this, but didn't succeed. The "Conten-Length"
HTTP-header attribute was always replaced by an
"Transfer-Encoding: chunked" attribute, when the request's
size exceeded some limit. (In the same way the phone's
modifying the "User-Agent" attribute, I guess).

Best regards,

Frank Gaebler

--
Frank Gaebler bit-side GmbH email: f.gaebler@bit-side.com

> -----Ursprüngliche Nachricht-----
> Von: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM] Im Auftrag von Joe Bowbeer
> Gesendet: Samstag, 9. Dezember 2006 00:56
> An: KVM-INTEREST@JAVA.SUN.COM
> Betreff: Re: Chunked Transfer Encoding
>
> On 12/8/06, Thomas Landspurg
wrote:
> > You mean re-implementing the HTTP protocol by myself? Is
> there any
> > other option?
> >
>
> Clarification: The problem is really on the server side, but
> you want to fix it in the mobile client, right?
>
> Can you send sample code? It's hard to debug this in the
> abstract, as you know.
>
> Are you sure you're not flushing the output stream before
> you've finished writing the data? I think this is the usual
> way that chunking gets triggered unintentionally.
>
> Are you sure you're setting content-length?
>
> --Joe
>
> ==============================================================
> =============
> To unsubscribe, send email to listserv@java.sun.com and
> include in the body of the message "signoff KVM-INTEREST".
> For general help, send email to listserv@java.sun.com and
> include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Frank Gaebler

[att1.html]

Thomas Landspurg

You mean re-implementing the HTTP protocol by myself? Is there any other
option?

On 12/7/06, Frank Gaebler wrote:
>
> Hi Thomas,
>
> one workaround for those uploads - although rather ugly - is to implement the
> HTTP request
> (using "Content-Length") on a raw socket connection. But be aware of
> additional security
> issues when opening Port 80 socket connections.
>
> Frank Gaebler
>
>
> --
> Frank Gaebler bit-side GmbH
> email: f.gaebler at bit-side dot com
>
>
> ------------------------------
> *Von:* A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
> *Im Auftrag von *Thomas Landspurg
> *Gesendet:* Montag, 4. Dezember 2006 17:53
> *An:* KVM-INTEREST@JAVA.SUN.COM
> *Betreff:* Chunked Transfer Encoding
>
>
>
> Does somebody was able to get ride of the famous "chunked encoding
> issue"?
>
> the problem raise when you try to send more than 2048 bytes of data
> through HTTP, it appears than J2ME then use chunked mode encoding.
> But many of the server does not understand chunked encoding. Some does
> (for instance, in mobup I was able to upload pictures to Flickr without
> problem), but on my apache server, I've got some errors when trying to
> access to a php page with a "chunked post"
>
> Logs show: "chunked Transfer-Encoding forbidden" in apache
>
> A search on the web shows that I am not the only one to have such issue,
> but did not found any solution on this yet. Any idea?
>
> Thanks for any suggestion/help
>
> --
> Thomas Landspurg
> http://blog.landspurg.net===============================================...
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

--
Thomas Landspurg
http://blog.landspurg.net

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Joe Bowbeer

On 12/8/06, Thomas Landspurg
wrote:
> You mean re-implementing the HTTP protocol by myself? Is there any other
> option?
>

Clarification: The problem is really on the server side, but you want
to fix it in the mobile client, right?

Can you send sample code? It's hard to debug this in the abstract, as you know.

Are you sure you're not flushing the output stream before you've
finished writing the data? I think this is the usual way that
chunking gets triggered unintentionally.

Are you sure you're setting content-length?

--Joe

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gary Adams

Chunking will also be used if an implementation has limited buffering
capabilities, and a full request can not be counted. e.g. to use HTTP
1.1 persistent connections either a Content-Length for the entire
transaction must be provided, or individual chunks with intermediate
chunk sizes must be provided.

Joe Bowbeer wrote:

> On 12/8/06, Thomas Landspurg
wrote:
>
>> You mean re-implementing the HTTP protocol by myself? Is there any
>> other
>> option?
>>
>
> Clarification: The problem is really on the server side, but you want
> to fix it in the mobile client, right?
>
> Can you send sample code? It's hard to debug this in the abstract, as
> you know.
>
> Are you sure you're not flushing the output stream before you've
> finished writing the data? I think this is the usual way that
> chunking gets triggered unintentionally.
>
> Are you sure you're setting content-length?
>
> --Joe
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Thomas Landspurg

Hello,

No, I would like to fix it on server side. The client must use as much as
possible "standard" HTTP implmentations. So doing it by myself won't work on
handset not supporting sockets.
I've tried to set up content length on the request, but it always fall
back in chunked mode....

So on the server side: I use apache with php. I did not see any option for
this?

Also, I am open to any other suggestion, like a proxy server, to change
the chunked request into an unchunked request.....

On 12/9/06, Gary Adams wrote:
>
> Chunking will also be used if an implementation has limited buffering
> capabilities, and a full request can not be counted. e.g. to use HTTP
> 1.1 persistent connections either a Content-Length for the entire
> transaction must be provided, or individual chunks with intermediate
> chunk sizes must be provided.
>
> Joe Bowbeer wrote:
>
>

--
Thomas Landspurg
http://blog.landspurg.net

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Gary Adams

What version of apache server is being used? Since Version 2.0,
I believe persistent connections have been the default behavior,
which is required by the HTTP 1.1 protocol.

Just because an application sets Content-Length, does not mean the
implementation can trust that value. It also may not have large
enough buffers to write large buffers. In which case the application
large data transfer may be broken into smaller chunks for transmission.

You might also be suffering from proxy servers that may be chunking
the stream as well. Your best bet is to find out which component
in the chain (http client, proxy server, or http server) is failing
to handle the chunked transfer encoding. My guess is you have an
HTTP 1.0 component somewhere in the chain. This is one reason some
implementations will use "tunneling" to get packets through an
HTTP 1.0 proxy between an HTTP 1.1 client and server.

Gary

Thomas Landspurg wrote:

> Hello,
>
> No, I would like to fix it on server side. The client must use as much
> as possible "standard" HTTP implmentations. So doing it by myself won't
> work on handset not supporting sockets.
> I've tried to set up content length on the request, but it always fall
> back in chunked mode....
>
> So on the server side: I use apache with php. I did not see any option
> for this?
>
> Also, I am open to any other suggestion, like a proxy server, to
> change the chunked request into an unchunked request.....
>
> On 12/9/06, *Gary Adams* > > wrote:
>
> Chunking will also be used if an implementation has limited buffering
> capabilities, and a full request can not be counted. e.g. to use HTTP
> 1.1 persistent connections either a Content-Length for the entire
> transaction must be provided, or individual chunks with intermediate
> chunk sizes must be provided.
>
> Joe Bowbeer wrote:
>
>
>
> --
> Thomas Landspurg
> http://blog.landspurg.net
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email
> to listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Thomas Landspurg

Hello Gary,

Tha fact is that it happens locally too, between the WTK and my Apache
running on the same host! So with this configuration, I am quite shure that
there is no gateway in between!
So I am quite sure it's linked to my apache configuration......It's
Apache/2.0.59 (Win32) with PHP/5.2.0 .

On 12/10/06, Gary Adams wrote:
>
> What version of apache server is being used? Since Version 2.0,
> I believe persistent connections have been the default behavior,
> which is required by the HTTP 1.1 protocol.
>
> Just because an application sets Content-Length, does not mean the
> implementation can trust that value. It also may not have large
> enough buffers to write large buffers. In which case the application
> large data transfer may be broken into smaller chunks for transmission.
>
> You might also be suffering from proxy servers that may be chunking
> the stream as well. Your best bet is to find out which component
> in the chain (http client, proxy server, or http server) is failing
> to handle the chunked transfer encoding. My guess is you have an
> HTTP 1.0 component somewhere in the chain. This is one reason some
> implementations will use "tunneling" to get packets through an
> HTTP 1.0 proxy between an HTTP 1.1 client and server.
>
> Gary
>
> Thomas Landspurg wrote:
>
> > Hello,
> >
> > No, I would like to fix it on server side. The client must use as much
> > as possible "standard" HTTP implmentations. So doing it by myself won't
> > work on handset not supporting sockets.
> > I've tried to set up content length on the request, but it always fall
> > back in chunked mode....
> >
> > So on the server side: I use apache with php. I did not see any option
> > for this?
> >
> > Also, I am open to any other suggestion, like a proxy server, to
> > change the chunked request into an unchunked request.....
> >
> > On 12/9/06, *Gary Adams* > > > wrote:
> >
> > Chunking will also be used if an implementation has limited
> buffering
> > capabilities, and a full request can not be counted. e.g. to use
> HTTP
> > 1.1 persistent connections either a Content-Length for the entire
> > transaction must be provided, or individual chunks with intermediate
> > chunk sizes must be provided.
> >
> > Joe Bowbeer wrote:
> >
> >
> >
> > --
> > Thomas Landspurg
> > http://blog.landspurg.net
> >
> ===========================================================================
> > To unsubscribe, send email to listserv@java.sun.com and include in the
> > body of the message "signoff KVM-INTEREST". For general help, send email
> > to listserv@java.sun.com and include in the body of the message "help".
>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

--
Thomas Landspurg
http://blog.landspurg.net

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Roger

Hi Thomas,

hu, Apache... Pigs might fly!

There's in fact no other chance than to make your server handle chunked
encoding. E.g. Nokia phones do always send POST content chunked. Maybe
not all, but one is enough, isn't it? And I know many of em.

Ever thought of setting up a tiny Tomcat? I bet Tomcat can handle with
it, even if Tomcat is running as Apache module. That means, Tomcat
shouldn't block the request at once. But I'm not really sure.

However, you would have to the parse the chunked body yourself within a
servlet. That's again no problem, once you obtain an InputStream via
InputStream=HttpServletRequest.getInputStream(). Should start with the
first chunk's length...

Ok I agree, that's a bit hard. But for the benefit of running a smart
server it might be worth the work.

Best,

Roger

Thomas Landspurg schrieb:
> Hello Gary,
>
>
> Tha fact is that it happens locally too, between the WTK and my
> Apache running on the same host! So with this configuration, I am
> quite shure that there is no gateway in between!
> So I am quite sure it's linked to my apache configuration......It's
> Apache/2.0.59 (Win32) with PHP/5.2.0 .
>
>
> On 12/10/06, *Gary Adams* > > wrote:
>
> What version of apache server is being used? Since Version 2.0,
> I believe persistent connections have been the default behavior,
> which is required by the HTTP 1.1 protocol.
>
> Just because an application sets Content-Length, does not mean the
> implementation can trust that value. It also may not have large
> enough buffers to write large buffers. In which case the application
> large data transfer may be broken into smaller chunks for
> transmission.
>
> You might also be suffering from proxy servers that may be chunking
> the stream as well. Your best bet is to find out which component
> in the chain (http client, proxy server, or http server) is failing
> to handle the chunked transfer encoding. My guess is you have an
> HTTP 1.0 component somewhere in the chain. This is one reason some
> implementations will use "tunneling" to get packets through an
> HTTP 1.0 proxy between an HTTP 1.1 client and server.
>
> Gary
>
> Thomas Landspurg wrote:
>
> > Hello,
> >
> > No, I would like to fix it on server side. The client must use
> as much
> > as possible "standard" HTTP implmentations. So doing it by
> myself won't
> > work on handset not supporting sockets.
> > I've tried to set up content length on the request, but it
> always fall
> > back in chunked mode....
> >
> > So on the server side: I use apache with php. I did not see
> any option
> > for this?
> >
> > Also, I am open to any other suggestion, like a proxy server, to
> > change the chunked request into an unchunked request.....
> >
> > On 12/9/06, *Gary Adams* < Gary.Adams@sun.com
>
> > >> wrote:
> >
> > Chunking will also be used if an implementation has limited
> buffering
> > capabilities, and a full request can not be counted. e.g. to
> use HTTP
> > 1.1 persistent connections either a Content-Length for the
> entire
> > transaction must be provided, or individual chunks with
> intermediate
> > chunk sizes must be provided.
> >
> > Joe Bowbeer wrote:
> >
> >
> >
> > --
> > Thomas Landspurg
> > http://blog.landspurg.net
> >
> ===========================================================================
>
> > To unsubscribe, send email to listserv@java.sun.com
> and include in the
> > body of the message "signoff KVM-INTEREST". For general help,
> send email
> > to listserv@java.sun.com and
> include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com
> and include in the body
> of the message "signoff KVM-INTEREST". For general help, send
> email to
> listserv@java.sun.com and include
> in the body of the message "help".
>
>
>
>
> --
> Thomas Landspurg
> http://blog.landspurg.net
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

--
/**************************
* Roger F. Hösl
* Engelthaler Str. 5
* 60435 Frankfurt
* Fon: (069) 79202638
* Mobil: 0172 1409984
* Fax: (069) 79202978
* Mail: roger@crazything.de
**************************/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Stefan Haustein

Hi Roger,

Tomcat handles chunked encoding internally, you should not see the hex
encoded chunk lengths in the input stream (if you would need to do all
the low-level stuff yourself, there would not be much gain from a HTTP
implementation, you could use raw sockets instead).

BTW: From the HTTP 1.1 spec, section 4.4: "If a Content-Length header
field (section 14.13
) is
present, its decimal value in OCTETs represents both the entity-length
and the transfer-length. The Content-Length header field MUST NOT be
sent if these two lengths are different (i.e., if a Transfer-Encoding
header field is present)"

Unfortunately, the MIDP specification does not seem to specify how/if
potential conflicts between a content-length header field set by the
user and chunked transfer encoding chosen by the system are resolved.

Best regards,
Stefan

Roger wrote:
> Hi Thomas,
>
> hu, Apache... Pigs might fly!
>
> There's in fact no other chance than to make your server handle
> chunked encoding. E.g. Nokia phones do always send POST content
> chunked. Maybe not all, but one is enough, isn't it? And I know many
> of em.
>
> Ever thought of setting up a tiny Tomcat? I bet Tomcat can handle with
> it, even if Tomcat is running as Apache module. That means, Tomcat
> shouldn't block the request at once. But I'm not really sure.
>
> However, you would have to the parse the chunked body yourself within
> a servlet. That's again no problem, once you obtain an InputStream via
> InputStream=HttpServletRequest.getInputStream(). Should start with the
> first chunk's length...
>
> Ok I agree, that's a bit hard. But for the benefit of running a smart
> server it might be worth the work.
>
> Best,
>
> Roger
>
>
>
>
>
>
>
> Thomas Landspurg schrieb:
>> Hello Gary,
>>
>>
>> Tha fact is that it happens locally too, between the WTK and my
>> Apache running on the same host! So with this configuration, I am
>> quite shure that there is no gateway in between!
>> So I am quite sure it's linked to my apache configuration......It's
>> Apache/2.0.59 (Win32) with PHP/5.2.0 .
>>
>>
>> On 12/10/06, *Gary Adams* >> > wrote:
>>
>> What version of apache server is being used? Since Version 2.0,
>> I believe persistent connections have been the default behavior,
>> which is required by the HTTP 1.1 protocol.
>>
>> Just because an application sets Content-Length, does not mean the
>> implementation can trust that value. It also may not have large
>> enough buffers to write large buffers. In which case the application
>> large data transfer may be broken into smaller chunks for
>> transmission.
>>
>> You might also be suffering from proxy servers that may be chunking
>> the stream as well. Your best bet is to find out which component
>> in the chain (http client, proxy server, or http server) is failing
>> to handle the chunked transfer encoding. My guess is you have an
>> HTTP 1.0 component somewhere in the chain. This is one reason some
>> implementations will use "tunneling" to get packets through an
>> HTTP 1.0 proxy between an HTTP 1.1 client and server.
>>
>> Gary
>>
>> Thomas Landspurg wrote:
>>
>> > Hello,
>> >
>> > No, I would like to fix it on server side. The client must
>> use as much
>> > as possible "standard" HTTP implmentations. So doing it by
>> myself won't
>> > work on handset not supporting sockets.
>> > I've tried to set up content length on the request, but it
>> always fall
>> > back in chunked mode....
>> >
>> > So on the server side: I use apache with php. I did not see
>> any option
>> > for this?
>> >
>> > Also, I am open to any other suggestion, like a proxy server, to
>> > change the chunked request into an unchunked request.....
>> >
>> > On 12/9/06, *Gary Adams* < Gary.Adams@sun.com
>>
>> > >> wrote:
>> >
>> > Chunking will also be used if an implementation has limited
>> buffering
>> > capabilities, and a full request can not be counted. e.g.
>> to use HTTP
>> > 1.1 persistent connections either a Content-Length for the
>> entire
>> > transaction must be provided, or individual chunks with
>> intermediate
>> > chunk sizes must be provided.
>> >
>> > Joe Bowbeer wrote:
>> >
>> >
>> >
>> > --
>> > Thomas Landspurg
>> > http://blog.landspurg.net
>> >
>> ===========================================================================
>>
>> > To unsubscribe, send email to listserv@java.sun.com
>> and include in the
>> > body of the message "signoff KVM-INTEREST". For general help,
>> send email
>> > to listserv@java.sun.com and
>> include in the body of the message "help".
>>
>> ===========================================================================
>> To unsubscribe, send email to listserv@java.sun.com
>> and include in the body
>> of the message "signoff KVM-INTEREST". For general help, send
>> email to
>> listserv@java.sun.com and include
>> in the body of the message "help".
>>
>>
>>
>>
>> --
>> Thomas Landspurg
>> http://blog.landspurg.net
>> ===========================================================================
>> To unsubscribe, send email to listserv@java.sun.com and include in
>> the body of the message "signoff KVM-INTEREST". For general help,
>> send email to listserv@java.sun.com and include in the body of the
>> message "help".
>
> --
> /**************************
> * Roger F. Hösl
> * Engelthaler Str. 5
> * 60435 Frankfurt
> * Fon: (069) 79202638
> * Mobil: 0172 1409984
> * Fax: (069) 79202978
> * Mail: roger@crazything.de
> **************************/
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Roger

Hi Stefan,

that's great. If Tomcat can handle with it, there's in fact no need for
doing the low level stuff (I should have known once...).

Ok, I see the problem isn't solved yet. At first sight it should ease
things by simply leaving out the Content-Length header in order to let
the mobile decide itself.

But if they really are too confused, one should look out for a way to go
round Tomcat's internal dechunker. Maybe
javax.servlet.ServletRequest.getInputStream will pass the original
Stream. If not, I would be the confused...

Best,

Roger

Stefan Haustein schrieb:
> Hi Roger,
>
> Tomcat handles chunked encoding internally, you should not see the hex
> encoded chunk lengths in the input stream (if you would need to do all
> the low-level stuff yourself, there would not be much gain from a HTTP
> implementation, you could use raw sockets instead).
>
> BTW: From the HTTP 1.1 spec, section 4.4: "If a Content-Length header
> field (section 14.13
> ) is
> present, its decimal value in OCTETs represents both the entity-length
> and the transfer-length. The Content-Length header field MUST NOT be
> sent if these two lengths are different (i.e., if a Transfer-Encoding
> header field is present)"
>
> Unfortunately, the MIDP specification does not seem to specify how/if
> potential conflicts between a content-length header field set by the
> user and chunked transfer encoding chosen by the system are resolved.
>
> Best regards,
> Stefan
>
>
>
> Roger wrote:
>> Hi Thomas,
>>
>> hu, Apache... Pigs might fly!
>>
>> There's in fact no other chance than to make your server handle
>> chunked encoding. E.g. Nokia phones do always send POST content
>> chunked. Maybe not all, but one is enough, isn't it? And I know many
>> of em.
>>
>> Ever thought of setting up a tiny Tomcat? I bet Tomcat can handle with
>> it, even if Tomcat is running as Apache module. That means, Tomcat
>> shouldn't block the request at once. But I'm not really sure.
>>
>> However, you would have to the parse the chunked body yourself within
>> a servlet. That's again no problem, once you obtain an InputStream via
>> InputStream=HttpServletRequest.getInputStream(). Should start with the
>> first chunk's length...
>>
>> Ok I agree, that's a bit hard. But for the benefit of running a smart
>> server it might be worth the work.
>>
>> Best,
>>
>> Roger
>>
>>
>>
>>
>>
>>
>>
>> Thomas Landspurg schrieb:
>>> Hello Gary,
>>>
>>>
>>> Tha fact is that it happens locally too, between the WTK and my
>>> Apache running on the same host! So with this configuration, I am
>>> quite shure that there is no gateway in between!
>>> So I am quite sure it's linked to my apache configuration......It's
>>> Apache/2.0.59 (Win32) with PHP/5.2.0 .
>>>
>>>
>>> On 12/10/06, *Gary Adams* >>> > wrote:
>>>
>>> What version of apache server is being used? Since Version 2.0,
>>> I believe persistent connections have been the default behavior,
>>> which is required by the HTTP 1.1 protocol.
>>>
>>> Just because an application sets Content-Length, does not mean the
>>> implementation can trust that value. It also may not have large
>>> enough buffers to write large buffers. In which case the
>>> application
>>> large data transfer may be broken into smaller chunks for
>>> transmission.
>>>
>>> You might also be suffering from proxy servers that may be chunking
>>> the stream as well. Your best bet is to find out which component
>>> in the chain (http client, proxy server, or http server) is failing
>>> to handle the chunked transfer encoding. My guess is you have an
>>> HTTP 1.0 component somewhere in the chain. This is one reason some
>>> implementations will use "tunneling" to get packets through an
>>> HTTP 1.0 proxy between an HTTP 1.1 client and server.
>>>
>>> Gary
>>>
>>> Thomas Landspurg wrote:
>>>
>>> > Hello,
>>> >
>>> > No, I would like to fix it on server side. The client must
>>> use as much
>>> > as possible "standard" HTTP implmentations. So doing it by
>>> myself won't
>>> > work on handset not supporting sockets.
>>> > I've tried to set up content length on the request, but it
>>> always fall
>>> > back in chunked mode....
>>> >
>>> > So on the server side: I use apache with php. I did not see
>>> any option
>>> > for this?
>>> >
>>> > Also, I am open to any other suggestion, like a proxy
>>> server, to
>>> > change the chunked request into an unchunked request.....
>>> >
>>> > On 12/9/06, *Gary Adams* < Gary.Adams@sun.com
>>>
>>> > >> wrote:
>>> >
>>> > Chunking will also be used if an implementation has limited
>>> buffering
>>> > capabilities, and a full request can not be counted. e.g.
>>> to use HTTP
>>> > 1.1 persistent connections either a Content-Length for the
>>> entire
>>> > transaction must be provided, or individual chunks with
>>> intermediate
>>> > chunk sizes must be provided.
>>> >
>>> > Joe Bowbeer wrote:
>>> >
>>> >
>>> >
>>> > --
>>> > Thomas Landspurg
>>> > http://blog.landspurg.net
>>> >
>>>
>>> ===========================================================================
>>>
>>>
>>> > To unsubscribe, send email to listserv@java.sun.com
>>> and include in the
>>> > body of the message "signoff KVM-INTEREST". For general help,
>>> send email
>>> > to listserv@java.sun.com and
>>> include in the body of the message "help".
>>>
>>>
>>> ===========================================================================
>>>
>>> To unsubscribe, send email to listserv@java.sun.com
>>> and include in the body
>>> of the message "signoff KVM-INTEREST". For general help, send
>>> email to
>>> listserv@java.sun.com and include
>>> in the body of the message "help".
>>>
>>>
>>>
>>>
>>> --
>>> Thomas Landspurg
>>> http://blog.landspurg.net
>>> ===========================================================================
>>>
>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>> the body of the message "signoff KVM-INTEREST". For general help,
>>> send email to listserv@java.sun.com and include in the body of the
>>> message "help".
>>
>> --
>> /**************************
>> * Roger F. Hösl
>> * Engelthaler Str. 5
>> * 60435 Frankfurt
>> * Fon: (069) 79202638
>> * Mobil: 0172 1409984
>> * Fax: (069) 79202978
>> * Mail: roger@crazything.de
>> **************************/
>> ===========================================================================
>>
>> To unsubscribe, send email to listserv@java.sun.com and include in the
>> body of the message "signoff KVM-INTEREST". For general help, send
>> email to listserv@java.sun.com and include in the body of the message
>> "help".
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

--
/**************************
* Roger F. Hösl
* Engelthaler Str. 5
* 60435 Frankfurt
* Fon: (069) 79202638
* Mobil: 0172 1409984
* Fax: (069) 79202978
* Mail: roger@crazything.de
**************************/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Ward Willats

> But many of the server does not understand chunked encoding. Some
>does (for instance, in mobup I was able to upload pictures to Flickr
>without problem), but on my apache server, I've got some errors when
>trying to access to a php page with a "chunked post"
>
> Logs show: "chunked Transfer-Encoding forbidden" in apache
>

Eh? Any HTTP/1.1 server, by definition, must handle chunked-transfer encoding.

Most senders used chunked-transfer when they cannot determine the
length of the data (entity-body) in advance. For example, the native
network stack on some J2ME platforms (apparently, if you give it more
than a 2K buffer worth), or the output of a PHP script or JSP on a
regular server.

Now....if the platform identifies the protocol as HTTP/1.0 _and_
tries to use chunked-transfer encoding...well...that would be
"undefined."

Perhaps this is what causes Apache to say it is forbidden?

-- Ward

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".