Transfer-Encoding is set depending on server

Hi everyone!
I have a serious problem concerning message encoding on different machines. On my development machine (running WinXP) I can send email messages perfectly with this code:
MimeMessagePreparator pwMessagePreparator = new MimeMessagePreparator() {
    public void prepare(MimeMessage mimeMessage) throws MessagingException {
    mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
    MimeMessageHelper message = new MimeMessageHelper(mimeMessage, false, "ISO-8859-1");
    message.setSubject("Engineering-Days - Neues Passwort");
    message.setTo(address);
    String messageText = "Hallo!\n\n" +
        "Dein Passwort wurde neu gesetzt. Es lautet jetzt: " + newPw + "\n" +
        "Logge Dich damit bitte auf der Homepage ein und �ndere unter \"Mein Konto\" das Passwort.\n\n" + 
    try {
        message.setText(new String(messageText.getBytes("ISO-8859-1")));
    } catch (UnsupportedEncodingException ex) {
        logger.error(ex);
        try {
            mailSender.send(pwMessagePreparator);
        } catch (MailException e) {
            logger.warn("Senden der Mail f�r User " + address + " nicht erfolgreich: " + e.getMessage());
        }The text is German, never mind its meaning, what counts is that there are umlauts in it. The message is displayed correctly, the header is also correct:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bitI set mail.smtp.allow8bitmime to true.
As soon as I deploy the code on my production machine, the header looks like this:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bitNo matter what I do, it is always set to 7bit. Therefore, the umlauts are not transmitted correctly. I also tried lots of different things, including setting the charset to different values, using MimeUtility and so on. Nothing worked.
Any suggestions are highly appreciated.
Best regards,
Jan-Philipp Stegh�fer

I now set the Tomcat Locale to de_CH. This had no effect on the encoding. I also changed the code and removed the MimeMessageHelper. It now looks like this:
MimeMessagePreparator pwMessagePreparator = new MimeMessagePreparator() {
     public void prepare(MimeMessage mimeMessage) throws MessagingException {
          //mimeMessage.setHeader("Content-Transfer-Encoding", "8bit");
          mimeMessage.setSubject("Engineering-Days - Neues Passwort", "ISO-8859-1");
          mimeMessage.addRecipient(RecipientType.TO, new InternetAddress(address));
          mimeMessage.setFrom(new InternetAddress("[email protected]"));
          mimeMessage.setText("Hallo!\n\n" +
               "Dein Passwort wurde neu gesetzt. Es lautet jetzt: " + newPw + "\n" +
               "Logge Dich damit bitte auf der Homepage ein und �ndere unter \"Mein Konto\" das Passwort.\n\n" , "ISO-8859-1");                  
try {
     mailSender.send(pwMessagePreparator);
} catch (MailException e) {
     logger.warn("Senden der Mail f�r User " + address + " nicht erfolgreich: " + e.getMessage());
}The problem remains. Is it possible that the switch from a Windows to a Linux machine causes this effect?
On the other hand, most e-mails are encoded with "quoted-printable". In this encoding, the special signs are encoded as a sequence of characters starting with '='. Can I force JavaMail to use this transfer encoding?
Message was edited by:
Jan-Philipp.Steghoefer

Similar Messages

  • Running mac OS 10.5.8, Using Mail 3.5, Text encoding set to Automatic. messages arrive, but the message is 200  lines of alphanumerics. Top says Content-Type: text/plain;      charset=utf-8 Content-Transfer-Encoding: base64.

    I use Mail 3.6 and some incoming email messages start with
    Content-Type: text/plain;
        charset=utf-8
    Content-Transfer-Encoding: base64
    then go on to 200+ lines of alphanumerics (mostly upper and lower case letters). 
    What causes this problem, how can I fix it?
    Text encoding is set to Automatic, and  I'm not using any fancy fonts.  Senders are usually
    sending from PCS that may well use Outlook.
    Rosemary C.  Chicago

    Does it look something like this...
    JVBERi0xLjYNJeLjz9MNCjMyNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9M
    ZW5ndGggMTU4L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQohx6hAp7lMT4WVkGpP6z3UpIQfO4eN
    QRbgjhTqX5mfaabWcvQk/hLnUX6MpKiXwist+RiaiGrzj8XGSNFXuvETWsnoPoV687Exvzo1KYV4
    jIuPmKXlRJvESTE/K2htJihPMS/o6fo3i+nHbTBRWpyrXSfmCPVEgsAzcyECvSU0Rz4MJsEXpdu6
    6u/hg1hlPkb2gpkUQJv50YtWhkD/Jg0KZW5kc3RyZWFtDWVuZG9iag0zMjUgMCBvYmoNPDwvRmls
    Check Mail>View>Message, does it say View Raw Source, Long Headers, or Default Headers?
    See if view Plaintext version helps.

  • 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

  • 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

  • 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.

  • Content-Transfer-Encoding Header missing?

    Hello,
    our Exchange 2013 CU 6 won't send "Content-Transfer-Encoding" Header when sending Mails to external Domains. (This Header is present if Mail stays within our Org)
    Already tried to set different Encodings - but without luck ... Exchange just won't generate this Header ...
    [PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets Use7Bit
    [PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseBase64
    [PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseQP
    Hope someone here can help me with this!?
    Thank you, bye from Austria
    Andreas Schnederle-Wagner

    Hi,
    I suggest try to re-start the Transport service after running the commands you mentioned.
    Please try to refer following KB to change the encoding type. I suggest make a backup before changing the value.
    How to change the method for transfer encoding after you apply Exchange 2007 SP1 to the Exchange 2007-based server that is running the Hub Transport role
    https://support.microsoft.com/kb/946641?wa=wsignin1.0
    Thanks
    If you have feedback for TechNet Subscriber Support, contact
    [email protected]
    Mavis Huang
    TechNet Community Support

  • 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 :)

  • Very slow Export to Media Encoder and Media Encoder connecting to dynamic link server

    My flow is this: Open After Effects CC, import an image sequence, go to File > Export > Add to Adobe Media Encoder Queue...
    Every other time i do this it will take 2-3 mins before Media Encoder even shows the splash screen, then it'll take another 1-2 mins to open.
    Next, I'll select my custom preset over on the right side of the window, then hit the Play button to begin encoding.  Sometimes nothing will happen at all, sometimes I'll see the Orange stripped bar on the lower left and the message Media Encoder connecting to dynamic link server and that'll last 5+ minutes and I end task to get out of AE and ME. Sometimes, ME will begin encoding right away and zip through the small animation sequence quickly without issue.
    I have WIndows 7 Pro, I'm on a work network with access to the internet  and AE has been updated 24 days ago.  I have a subscription and I'm signed on.  However, sometimes I do not have the Creative-Cloud icon in my systray.
    Thanks,

    Thanks.  I have 16GB Ram, 64bit Win7,  Intel(R) Core(TM) i7-3970X @ 3.50GHz 3.50GHz.  AE is set to have maximum disk cache of 46GB. RAM reserved for other applications: 5GB RAM available for AE, PR, Pl, (some triangular icon [edit] which is ME ), Ps: 10GB. nothing else checked on that screen.
    Typically just a mail client, 1 or 2 sessions of Firefox, 1 or 2 network folders open when i launch AE.
    The last couple of times specifically, i had a 450 frame animation sequence at native 720p.  then i added a curves layer on top of it in AE, then added two ~600x300px  logos, one in each lower corner, then added a new solid layer which i used as a vignette. Finally over that i added a 720p still image which i held for another 15 seconds beyond the animation.
    For the above, i ended-task, rebooted, brought it up again and it lauched ME quickly, then i got the stripped bar and connecting message until i ended task on that, then the 3rd time was the charm - everything opened quickly and it began to encode quickly.
    The next three uses late afternoon yesterday were 150 frame animations at 480x270 and they all seemed to work fine.  I created the sequence in 3ds max, then closed and went into AE.  Then I'd close AE render another sequence, back into AE etc...

  • How to change Content-Transfer-Encoding for mail sending

    Hello Experts,
    I need to send some documents through mail which i am doing with the help of cl_output_service=>document_output method. Mail is been send succesfully.
    But in the payload content which got from Exchange server:
       X-Mailer: SAP Web Application Server 7.10
       Content-Type: text/plain;
        charset="us-ascii"
       Content-Transfer-Encoding: quoted-printable
    Can any one help me, how i can change Content-Transfer-Encoding field to some other format which is not  'quoted-printable'.
    Thanks & Regards,
    Dheeraj

    Do you documents contain an XML Declaration like this at the top?
    <?xml version="1.0" encoding="ISO-8859-2"?>
    If not, then they need to. The XML 1.0 specification says that if an XML declaration is not present, the processor must default to assume its in UTF-8 encoding.

  • I want to convison the mail body 's Content-Transfer-Encoding to base64

    Return-Path: <[email protected]>
    Received: from tobacco ([130.130.160.76]) by webapp.tobacco
    (Netscape Messaging Server 3.6) with ESMTP id AAA70AC;
    Tue, 6 Nov 2001 18:26:28 +0800
    type: ���� intra@ius_center 1670
    subject: ������gggggg��
    Content-Type: text/html; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Date: Tue, 6 Nov 2001 18:26:28 +0800
    Message-ID: <[email protected]>
    From: [email protected]
    <center><h1>����</h1><TABLE BORDER=1 CELLPADDING=5 width=90%%>
    <TR><TD BGCOLOR=#CCCC99 width=74 valign=top><STRONG>��������</STRONG></TD><TD BGCOLOR=#EEEEEE>gggggg</TD> </tr>
    <TR><TD BGCOLOR=CCCC99 VALIGN=TOP><STRONG>�� �� ��</STRONG></TD><TD BGCOLOR=#EEEEEE>������ ������������������</td></tr>
    <tr><TD BGCOLOR=#CCCC99 VALIGN=TOP><STRONG>�� �� ��</STRONG></TD><TD BGCOLOR=#EEEEEE >������ ������������������</td></tr>
    <tr><TD BGCOLOR=#CCCC99 VALIGN=TOP><STRONG>��������</STRONG></TD><TD BGCOLOR=#EEEEEE >fdsf</td></tr></TABLE>

    Me too. I want to find out what encoding a particular $INPUT_FILE part is when I need to parse it in my conversions script.

  • 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.

  • 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"?
              

  • Email Prob - Content-Transfer-Encoding: base64

    Using APEX to send an email to a CA product. We are doing this successful with another source (not Apex). The email that is sent opens a Help Desk ticket in the CA tool.
    Another development tool has the this in the mime.822 file:
    Content-Transfer-Encoding: 8 bit
    The email send from APEX has Content-Transfer-Encoding: base64.
    The look of the emails are different, this is why it is not working correctly when sent from APEX.
    Does anyone know about base64 versus 8-bit?

    Steve,
    >> Yes, I am sure. This all being done inside our firewall and domain.
    For an e-mail message to get from point A to point B, it must go through some message transfer agent somewhere, regardless whether it's all within the same firewall, domain, or otherwise.
    >> Is there a work-around for this?
    There can only be a workaround when the definitive problem has been identified. That has not been done.
    I just sent myself a message from apex.oracle.com, which is running APEX 3.0.1. I examined the entire message source in Thunderbird. I found no occurrence of Content-Transfer-Encoding in my message whatsoever. Hence, I believe this is not APEX which is injecting this into your message.
    My suggestion - take a look at what your SMTP server settings are for your APEX instance. Ensure that you are routing your e-mail to the SMTP server which works from the other "source" which is done successfully.
    Joel

Maybe you are looking for