Chunked transfer encoding problem

Hi guys, I think I'm going to lose my mind with this, I cant make my chunked transfer manager to work right.
The problem I'm having is that reading the amount of data specified in the chunk-size, I end up having the next chunk size inside the body, so, when I call the next getchunksize, it fails.
The first call to getChunkSize() works great and I get the size value as expected.
The BufferedReader is connected to the sock
s = new Socket(connectTo, portNum);
sIn = new BufferedReader(new InputStreamReader(s.getInputStream()) );Thanks a lot guys, I hope any of you understands what's going on...
private String processChunked(BufferedReader sIn, String newData) throws IOException {
        newData += LINEBREAK; // Let's separate header form body   
        int size = 0;
        String body = new String();
        size = getChunkSize(sIn);
        while(size > 0) {
            body = getChunkData(sIn, size);           
            size = getChunkSize(sIn);
            newData += body;
            body = "";
        return newData;
    private String getChunkData(BufferedReader sIn, int lenght) throws IOException {
        int val = 0;
        String res = new String();
        char chr = ' ';
        for(int i= 0; i<lenght; i++) {
            val = sIn.read();
            if(val == -1)
                break;
            chr = (char)val;
            res += Character.valueOf(chr).toString();
        return res;
    private int getChunkSize(BufferedReader sIn) throws IOException {
        char chr = ' ', prvChr = ' ';
        int val = 0;
        String tmpSize = new String();
        int size = 0;
        int readed = 0;
        do { //Read chunk size
            prvChr = chr;
            val = sIn.read();
            if (val == -1) {
                break;
            readed++;
            chr = (char) val;
            tmpSize += Character.valueOf(chr).toString();
        } while (prvChr != '\r' && chr != '\n');
        // calculate chunk size
        if(tmpSize.indexOf(";") != -1) { //remove chunk extension
            tmpSize = tmpSize.substring(0, tmpSize.indexOf(";"));
        tmpSize = tmpSize.trim();
        try {
            size = Integer.valueOf(tmpSize, 16);           
        } catch (NumberFormatException e) {
            size = 0;
        return size;
    }

Hi,
The spec requires that HTTP/1.1 is used. So for POST, instead of sending data directly, the client send just a message to have a confirmation from the server ( 100 CONTINUE packet), and then sends data (other packet(s) ). Of course, This mechanism is used only when we need more than 1 packet, that's why you don't see problems with less than x bytes.
The server don't need to be written differently because the final packet it receives is one packet after reconstitution from all sent packets.
Cheers,
Zak

Similar Messages

  • Chunked Transfer Encoding - Doesn't work due to implementation bug?

    Hello All,
    I'm tackling the infamous "transfer-encoding: chunked" issue on trying to send POST data from the J2ME emulators and devices greater than 2048 bytes (or whatever the internal buffer size of a specific device might be). The nginx server on the other end always sends back a *411 - No content length specified* because it doesn't seem to recognize chunked transfer encoding. (despite the fact nginx is HTTP 1.1 compliant meaning it should be able to recognize it without rejection)
    One thing I've noticed is that compared to a correctly chunked HTTP body which looks something like this:
    *2*
    ab
    *4*
    abcd
    A
    *0123456789*
    *3*
    foo
    *0*
    the HTTP bodies coming out of the MIDlet though Network Monitor in the emulator just look like this:
    ababcd0123456789foo
    It seems the chunked HTTP body does not have the chunk size indices that should be there for proper formatting.
    I did my debugging on the Sun Java Network Monitor and maybe that tool "hides" the actual chunking indices
    or the chunking takes place at a point beyond the emulator's snapshot of the data. Does anyone know if the Sun Java Network Monitor indeed shows the entire body of an HTTP POST in it's true state? The size of one packet I'm looking at is 2016 which is 32 bytes off 2048 - the supposed limit where data starts getting chunked. Could this "missing" 32 bytes from the log be the chunking indexes I am looking for? If the Network Monitor indeed shows the packet body in it's entirety then it seems like people are having issues sending chunked transfers because the format is wrong.
    Anyway assuming J2ME's chunked transfer encoding is working correctly then how come nginx and many other supposedly HTTP 1.1 servers cannot understand the incoming format? Is Java's implementation of chunked transfer encoding somehow deviant from the set standard? I read a post at the following address
    http://forum.java.sun.com/thread.jspa?forumID=76&threadID=454773
    in which a user could not get chunked posts recognized by Apache until he changed the format of his HTTP body (read the last post on that thread for details on this).
    In case no one can assist on the above how would I go about trying to intercept the HTTP data stream right after it leaves the emulator or a real device. Is this something that can only be done server side? If so how can I guarantee that the data I am receiving on the server side was not modified by another entity along the way?
    Any help on this would be much appreciated. Thanks.
    -Bob

    We're still tackling the same issue but we've made a few discoveries:
    * Nginx does not support chunked transfer encoding despite it's HTTP 1.1 status.
    * The chunked transfer encoding format coming out of J2ME is correct. During some server side logging sessions we found that J2ME puts in the chunking indices and the finalizing 0 and carriage return to signify the end of the stream.
    * The missing 32 bytes not shown in the Sun Java Network Monitor are the chunking indices - they are just hidden from you at that level of display. Since the J2ME emulator sends it's packets in 2048 bytes chunks when viewing the monitor you will just see the contents itself (2016 byte chunks). The other 32 bytes are the headers i.e.
    7e0[carriage return]
    which is a 32 bytes sequence (4 8 byte characters) with the last character being the carriage return. 7e0 in decimal is 2016 - the size of the displayed packet in the network monitor.
    Anyone have any suggestions for a reliable server end receiver for chunked transfer encoding content? (preferably one which works well with Ruby on Rails)

  • Turn off chunked transfer-encoding

    Hi. I have to interface with another company's client that has a broken implementation
    of http/1.1 and does not understand chunked transfer encoding. Is there some way
    I can tell Weblogic not to use chunked encoding for a particular servlet response?

    Nagesh Susarla <[email protected]> wrote:
    Joe Humphreys wrote:
    Hi. I have to interface with another company's client that has a brokenimplementation
    of http/1.1 and does not understand chunked transfer encoding. Is theresome way
    I can tell Weblogic not to use chunked encoding for a particular servletresponse?
    >
    The easiest way would be to set content-length on the response
    and the response wudnt be chunked
    -nagesh
    Thanks, but that is not an option here because the content is dynamic and may
    be in excess of 100K. I can't afford to buffer that much data in memory just to
    count its length. Since the server doesn't use chunked transfer-coding for http/1.0
    responses, I was hoping there would be some way to just turn it off. (But only
    for particular servlets.)
    Joe H

  • JSP transfer-encoding: other that chunked?

    Is it somehow possible not to use the chunked transfer encoding in JSP pages? I am using Tomcat 4.0.3 and there seems to be problems with Java Web Start and the chunked encoding.. (see my other topic "Chunked encoding")..

    I found the workaround that I was looking for:
    I added the argument allowChunking="false" to the Tomcat configuration file.
    The actual bug that causes the problem is most propably in JRE 1.3..

  • How to read the content of  "Transfer-Encoding: chunked" header

    Can anybody tell me how to get or read the value of transfer encoding.
    I got the HTTP Response header as "Transfer-Encoding: chunked".But i can't get the chunk size or the chunked data.
    Without getting those details i cant read the content of the site.If Content-Length is in the HTTP header,i can read upto that length.But in this Transfer-Encoding case,i cant know any other details except the value "chunked".So suggest me to read the content of the site using Transfer-Encoding.
    Message was edited by:
    VeeraLakshmi

    I used HTTPURLConnection also.If i use that am getting the values in request headers only and not in Response headers.So i cant read the content.
    Then i went through RFC 2616.There i can only understand about chunked transfer encoding.Still i cant get any idea to know the chunk-size and the chunked data of the transfer encoding.Because i am getting the HTTP Header Response as "Transfer-Encoding: chunked".Below that am not getting the size and data.If i know the size or data,i can proceed by converting the hex into bytes and i can read.

  • Transfer-Encoding: chunked

    Hi
    I'm creating an http client.. but got problems with the chunked data encoding.. does anybody know a link where there is more info about it? how much should I read from each chunk and where is it written? did anybody face such a problem before? My client tells the server it's firefox:
    GET / HTTP/1.1
    Host: mail.yahoo.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    and the server sends this:
    HTTP/1.1 200 OK
    Date: Sun, 25 Sep 2005 13:45:31 GMT
    P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
    Cache-Control: private
    Connection: close
    Transfer-Encoding: chunked
    Content-Type: text/html
    Content-Encoding: gzip
    Set-Cookie: B=9dikf6d1jdafr&b=3&s=5m; expires=Tue, 02-Jun-2037 20:00:00 GMT; path=/; domain=.yahoo.com
    1562
    please help!
    hmm.. looks like nobody is gonna answer.. :(

    3.6.1 Chunked Transfer Coding
    The chunked encoding modifies the body of a message in order to
    transfer it as a series of chunks, each with its own size indicator,
    followed by an OPTIONAL trailer containing entity-header fields. This
    allows dynamically produced content to be transferred along with the
    information necessary for the recipient to verify that it has
    received the full message.
    Chunked-Body = *chunk
    last-chunk
    trailer
    CRLF
    chunk = chunk-size [ chunk-extension ] CRLF
    chunk-data CRLF
    chunk-size = 1*HEX
    last-chunk = 1*("0") [ chunk-extension ] CRLF
    chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    chunk-ext-name = token
    chunk-ext-val = token | quoted-string
    chunk-data = chunk-size(OCTET)
    trailer = *(entity-header CRLF)
    The chunk-size field is a string of hex digits indicating the size of
    the chunk. The chunked encoding is ended by any chunk whose size is
    zero, followed by the trailer, which is terminated by an empty line.
    The trailer allows the sender to include additional HTTP header
    fields at the end of the message. The Trailer header field can be
    used to indicate which header fields are included in a trailer (see
    section 14.40).
    A server using chunked transfer-coding in a response MUST NOT use the
    trailer for any header fields unless at least one of the following is
    true:
    a)the request included a TE header field that indicates "trailers" is
    acceptable in the transfer-coding of the response, as described in
    section 14.39; or,
    b)the server is the origin server for the response, the trailer
    fields consist entirely of optional metadata, and the recipient
    could use the message (in a manner acceptable to the origin server)
    without receiving this metadata. In other words, the origin server
    is willing to accept the possibility that the trailer fields might
    be silently discarded along the path to the client.
    This requirement prevents an interoperability failure when the
    message is being received by an HTTP/1.1 (or later) proxy and
    forwarded to an HTTP/1.0 recipient. It avoids a situation where
    compliance with the protocol would have necessitated a possibly
    infinite buffer on the proxy.
    An example process for decoding a Chunked-Body is presented in
    appendix 19.4.6.
    All HTTP/1.1 applications MUST be able to receive and decode the
    "chunked" transfer-coding, and MUST ignore chunk-extension extensions
    they do not understand.

  • Transfer-encoding: chunk

    Hello,
    we are useing SunOne Webserver 6.1SP3.
    We have some Problems with sending pdf to the
    MS IE it seems that not the total document is send to
    the Browser or that there are some errors in the connection
    between Server an Browser. It is possible that the IE has a Problem with the Transfer-encoding: chunk ?
    Can we switch it off or can we change it for some mime-types?
    Thanks for your help.

    That seems unlikely; chunked encoding is a central part of HTTP/1.1.
    Perhaps you could be more specific about the problem. For example, why do you think there are problems sending PDF files? What appears in MSIE? Which versions of MSIE and Acrobat appear to be affected? What do the corresponding access log entries look like? Is anything written to the errors log?

  • Help me...How to read the content if "Transfer-Encoding:chunked" is used?

    I am doing a project for internet control using Java,PHP and MySql.All sites should go through the proxy server only.If the HTTP header contains Content-Length,am getting the content length as below:
    public class HTTPResponseReader extends HTTPMessageReader
        String statusCode;
        public HTTPResponseReader(InputStream istream) throws IOException,                     NoSuchElementException
      BufferedInputStream distream = new BufferedInputStream(istream);
      retrieveHeader(distream);
      StringTokenizer st =  new StringTokenizer(new String(HTTPMessageReader.toArray(header)));
      versionProtocol = st.nextToken();
      statusCode = st.nextToken();
      String s;
      while (st.hasMoreTokens())
            s = st.nextToken();
            if (s.equals("Transfer-Encoding:"))
           transferEncoding = new String(st.nextToken());
         if (s.equals("Content-Length:"))
           contentLength = Integer.parseInt(st.nextToken());
         if (s.equals("Connection:"))
          connection = new String(st.nextToken());
          if (connection.equals("keep-alive")) mustCloseConnection = false;
       retrieveBody(distream);     
    }After getting the Content-Length,i used read method to read the content upto that content length.Then i concatenated the HTTP header and body and the requested site was opened.But some sites dont have Content-Length.Instead of that,Transfer-Encoding is used.I got the HTTP Response header as "Transfer-Encoding:chunked" for some sites.If this encoding is used how to get the length of the message body and how to read the content.
    Can anybody help me.
    Thanks in advance...
    Message was edited by:
    VeeraLakshmi

    Why don't you use HttpUrlConnection class to retrieve data from HTTP server? This class already supports chunked encoding...
    If you want to do anything by yourself then you need to read HTTP RFC and find all required information. Well in two words you may reject advanced encoding by specifying HTTP 1.0 in your request or download chunked answer manually. Read RFC anyway :)

  • Problem in servlet engine (WLS 7.0) with the chunked transfer

    Hi,
              While using jakarta-slide on weblogic 7.0, I encountered the following
              problem while uploading files using WebDAV servlet deployed on WLS:
              "**** This file has a corrupted %%EOF marker, or garbage after the
              %%EOF."
              Is this is a problem with the way that WLS servlet engine is handling
              chunked transfers ?
              According to the change request 084847, "For chunked
              transfer, WebLogic Server was including a hexadecimal number which
              other
              servlet engines used to ignore. This has been fixed WLS 6.1 sp 4."
              Is this fixed in WLS 7.0 ? I could not find this in the resolved bugs
              list for WLS 7 SP1. If this has not been fixed in 7.0, any idea when
              this fix would make it to WLS 7.0 ?
              Any pointers would be of great help.
              Thanks,
              Jeeji.
              

    Hi,
              While using jakarta-slide on weblogic 7.0, I encountered the following
              problem while uploading files using WebDAV servlet deployed on WLS:
              "**** This file has a corrupted %%EOF marker, or garbage after the
              %%EOF."
              Is this is a problem with the way that WLS servlet engine is handling
              chunked transfers ?
              According to the change request 084847, "For chunked
              transfer, WebLogic Server was including a hexadecimal number which
              other
              servlet engines used to ignore. This has been fixed WLS 6.1 sp 4."
              Is this fixed in WLS 7.0 ? I could not find this in the resolved bugs
              list for WLS 7 SP1. If this has not been fixed in 7.0, any idea when
              this fix would make it to WLS 7.0 ?
              Any pointers would be of great help.
              Thanks,
              Jeeji.
              

  • Cannot upload with Transfer-Encoding: chunked

    Hi,
    I am unable to upload a file with Transfer-Encoding: chunked. I am using Jakarta Commons HttpClient:
    PutMethod method=new PutMethod("http://myhost.com/test/uploaded.txt");
    method.setContentChunked(true);
    method.setRequestEntity(new StringRequestEntity("uploaded", "text/plain", "iso-8859-1"));
    client.executeMethod(method);I get the following log output:
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "PUT /test/uploaded.txt HTTP/1.1[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "Authorization: Basic myauth[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "User-Agent: Jakarta Commons-HttpClient/3.0[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "Host: myhost.com[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "Transfer-Encoding: chunked[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "Content-Type: text/plain; charset=iso-8859-1[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "8[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "uploaded"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "0"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: >> "[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "HTTP/1.1 201 Created[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "Server: Sun-ONE-Web-Server/6.1[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "Date: Mon, 06 Mar 2006 11:26:24 GMT[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "Content-type: text/html[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "Transfer-encoding: chunked[\r][\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "0"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "0"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "b"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "d"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\r]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<html><head>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<title>201</title>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "</head><body>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<h1>Created</h1>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<p>Resource /test/uploaded.txt has been created.</p>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "<hr />[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "</body></html>[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\r]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "0"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\r]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\n]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\r]"
    6 mars 2006 12:20:42 org.apache.commons.httpclient.Wire wire
    FIN: << "[\n]"
    all looks fine, but the uploaded.txt is empty.
    Note without Transfer-Encoding: chunked, all is OK.
    Any help would be greatly appreciated.
    Regards,
    Laurent.

    Note I get a HTTP 204 no content, once the file is already created:
    6 mars 2006 12:43:08 org.apache.commons.httpclient.Wire wire
    FIN: << "HTTP/1.1 204 No Content[\r][\n]"
    6 mars 2006 12:43:08 org.apache.commons.httpclient.Wire wire
    FIN: << "Server: Sun-ONE-Web-Server/6.1[\r][\n]"
    6 mars 2006 12:43:08 org.apache.commons.httpclient.Wire wire
    FIN: << "Date: Mon, 06 Mar 2006 11:48:50 GMT[\r][\n]"

  • It's possible to disable "Transfer-Encoding: chunked" in WebDAV Finder PUT requests ?

    Hi,
    Since Mac OS X 10.5.4 version, Apple WebDAV finder client use "Transfer-Encoding: chunked" in PUT request.
    Very very few HTTP Server, HTTP Proxy support this feature.
    Are there a flag to disable this feature ? If not, can you append it in futur OS X version ?
    Thanks for your help,
    Stephane

    PUT requests will cause your servlet's doPut() method to be called, and DELETE requests will cause your servlets's doDelete() method to be called. So if you don't provide any implementation of those methods, nothing will happen. Unless you are overriding the service() method to do your processing, which is not recommended.

  • Apache Proxy Plug-in with WebLogic 8.1 SP5 - Transfer Encoding:Chunked

    Hello All,
    Configuration: Apache 2.0.48
    Plugin - mod_wl128_20.so
    WebLogic Version - 8.1 SP5
    There is no SSL between Apache and WebLogic server.
    Apache seems to have issue when the response from WebLogic has: Hdrs from WLS:[Transfer-Encoding]=[chunked]
    I turned on the debugging on Apache side with DebugAll flag and WLS sends data to Apache plug-in.
    Is is a known issue? Is there any CR to fix it? Please let me know if you need further details.
    Any help is appreciated.
    Thanks,
    Janani

    Hi Vishwas,
    Thank you for the reply. I forgot to mention that Apache and WebLogic are on Solaris 9 platform.
    Accesing a webapp hosted on WebLogic through Apache->plug-in->WebLogic return 500 internal server error, but other webapps hosted on the same WebLogic domain works properly. Looking at the Response Hdrs from WebLogic shows that WLS returns transfer-encoding=chunked. The other webapps which work properly has content-length set and transfer-encoding is not chunked.
    So, the question is does Apache Plug-in for weblogic 8.1 SP5 read the chunked data properly?
    Thanks,
    Janani

  • Why adding "Transfer-Encoding: chunked"?

    I have a servlet which generating dynamic content for client, e.g, a JAR file for user to download. Since it's a binary file, in doGet() method, I use ServletOutputStream.write() to output bytes. And I explictly called setIntHeader("Content-Length", xxx). But in most cases, the client will get a HTTP response whose header includes "Transfer-Encoding: chunked" and it causes some error. I know it's the client's fault, but is there anyone tell me why WebLogic adds this "chunked" header to my servlet even I set "Content-Length"?
              

    I see the exact same behaviour, (had to fix the clients; they should have to
              handle chunked
              transfers if they're truely 1.1 compliant).
              My issue is WL sends both a chunked response AND a Content-Length (even when
              I don't
              set it) and this is HTTP 1.1 non-compliant. - A bug.
              -simon tooke
              [email protected]
              "Tim Bao" <[email protected]> wrote in message
              news:3befdbda$[email protected]..
              > I have a servlet which generating dynamic content for client, e.g, a JAR
              file for user to download. Since it's a binary file, in doGet() method, I
              use ServletOutputStream.write() to output bytes. And I explictly called
              setIntHeader("Content-Length", xxx). But in most cases, the client will get
              a HTTP response whose header includes "Transfer-Encoding: chunked" and it
              causes some error. I know it's the client's fault, but is there anyone tell
              me why WebLogic adds this "chunked" header to my servlet even I set
              "Content-Length"?
              

  • HTTP Transfer Encoding

    Hello, I have some troubles in a Web Service using Axis that is called from a Power Builder Software. The problem comes from the HTTP Transfer Encoding at Power Builder 9. I need to disable the Chunked Tranfer or change the HTTP1.1 to HTTP1.0. I�ve tried both but the caller always have Transfer Chunked!! I�m trying to set the properties og the Message Context:
    MessageContext context = MessageContext.getCurrentContext();  
             context.setProperty("HTTP_PROTOCOL_VERSION",org.apache.axis.transport.http.HTTPConstants.HEADER_PROTOCOL_10);           ;
    Anyone can help me ??

    Message was edited by:
    user615271

  • Please shed some light on Chunked Transfer Coding for HTTP 1.1?

    I am writing a HTTP proxy in Java, but I have a problem. I am writing a HTTP 1.0 proxy. As you probably know, HTTP 1.0 determines the length of the message body using Content-Length and HTTP 1.1 server are supposed to send a Content-Length header to HTTP 1.0 clients. However, several sites like Myspace is very buggy and do not do this. Could someone explain what the Chunked Transfer Coding is for HTTP 1.1? I read the documentation here http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 but it's all greek to me :(. Can anybody give me code/hints on how to deal with this?
    Thanks in advance.

    Hi, Toshi:
    Most of these chat boards have become quite boring. Troubleshooting OSPF LSA problems is old news. But I do pop my head in every now and then. Also, there are so many other companies out there doing exciting things in the data center. You have Dell, Brocade, Arista, Juniper, etc. So one runs the risk of developing a myopic view of the world of IT by lingering around this board for too long.
    If you want to use the new B22 FEX for the HP c7000 blade chassis, you certainly can. That means the Nexus will receive the FCoE traffic and leverage its FCF functionality; either separate the Ethernet and FC traffic there, or create a VE-port instantiation with another FCF for multihop deployments. Good luck fighting the SAN team with that one! Another aspect of using the HP B22 is the fact that the FEX is largely plug and play, so you dont have to manage the Flex Fabric switches.
    HTH

Maybe you are looking for

  • Removing ink cartridge from HP office jet 6600 printer

    I replaced all four ink cartridges in my HP Officejet 6600 printer (almost new) and now I can't get the black cartridge out.  The original cartrige was a 932 and I replaced it with a 932XL so it is larger than the original one.  It seems to be jammed

  • Itunes store, emergency....

    My phone was bought in england, so it has the english itunes store, but now i have moved to spain and i want to change the english store to the spanish one, but it wont let me because ive got 33p on my account and it tells me that i need to spend it,

  • HR Authorization

    Hi All, Anyone worked on HR Authorization ? My project has a great difficulty regarding HR authorization. Is there a doc. specific to this topic, (not the general authorization) or any pointers..??? This is in BI 7.0 Thanks. Vaishali

  • How to get photos from one iPad two another keeping the original

    My mom bought an iPad 2  I want to transfer photos from my ipad 2 to her photo folder on her new iPad.  Not exactly sure how to do it. Hoping someone can advise me. Thanks

  • VGA-enabled app for projecting docs in iPad 1

    I'm looking for a VGA-enabled app able to project simple text and PDF documents to a projector through a VGA adapter on an iPad 1. There appear to be lots of VGA-enabled apps for projecting things, but few of them seem to work with iOS 5. Many of the