Hello Paul,
I have performed this test using LiteHTTP which doesn't send the 100-continue header and everything worked fine. To recap: the 100-continue header was the cause of the issue, it still remains an issue when using WCF's own HTTP, but there is no problem when using LiteHTTP.
With best regards,
Arman
Arman Djusupov wrote:
> Hi,
>
> The 100-continue is not sent by our WCF-Xtensions but by MSFT code which
> is out of my direct control. We've had trouble with this before. I will
> inverstigate whether our own LiteHTTP transport can be used instead of
> the system-provided HTTP implementation. LiteHTTP can suppress
> 100-continue nicely. I will let you know.
>
> With best regards,
> Arman
>
> Paul Sandoz wrote:
>>
>> On Jul 9, 2009, at 3:29 PM, Arman Djusupov wrote:
>>
>>> Hi,
>>>
>>> Nope, commenting out these lines didn't resolve the issue.
>>
>> Ah! i see the following header, sent by the client
>>
>> Expect: 100-continue
>>
>> http://greenbytes.de/tech/webdav/rfc2616.html#use.of.the.100.status
>>
>> Is it possible to configure the client side not to send that header ?
>>
>> I think this explains why GZIPInputStream returns an EOF. The client
>> is expecting the server to return with a status code of 100 before the
>> client sends the request body.
>>
>> Jersey does not currently have support for 100-continue. It is not
>> something that is possible to support in Servlet 2.x API AFAIK, but i
>> am sure using the Grizzly APIs it might be possible.
>>
>> Paul.
>>
>>
>>> With best regards,
>>> Arman
>>>
>>> Paul Sandoz wrote:
>>>> Hi,
>>>> Are you still doing ?
>>>> threadSelector.setCompression("on");
>>>> threadSelector.setCompressableMimeTypes("application/fastinfoset");
>>>> threadSelector.setCompressionMinSize(0);
>>>> In addition to including the Jersye filter? i am wondering if
>>>> Grizzly is decompressing, then Jersey is attempting to decompress
>>>> after.
>>>> Paul.
>>>> On Jul 9, 2009, at 1:50 PM, Arman Djusupov wrote:
>>>>> Hello Paul,
>>>>>
>>>>> Thanks a lot for the link. It worked fine at least for response
>>>>> compression :-)
>>>>> But when I try to POST a compressed HTTP message to a Jersey
>>>>> resource, I get an exception on the Jersey side. This is the header
>>>>> of the request that fails to decompress:
>>>>>
>>>>> POST /tickhistory/ HTTP/1.1
>>>>> VsDebuggerCausalityData:
>>>>> uIDPo9PKOzKg7z1DuyaISwKJUpgAAAAAdxwoWxKXH0OxvewI3bswnOraGVvVFg5NvTB+/pg8Cs8ACQAA
>>>>>
>>>>> Accept-Encoding: gzip
>>>>> Accept: application/fastinfoset,application/xml; charset=utf-8
>>>>> Content-Encoding: gzip
>>>>> Content-Type: application/fastinfoset
>>>>> Host: 192.168.1.22:9998
>>>>> Content-Length: 3289
>>>>> Expect: 100-continue
>>>>>
>>>>> The body seems to be of valid size. Also, when I save it into a
>>>>> file it can be decompressed and the FI content can also can be
>>>>> decoded. I have attached the message body to this email.
>>>>>
>>>>> The exception that I get on Grizzly is EOFException.
>>>>> SEVERE: service exception:
>>>>> javax.servlet.ServletException:
>>>>> com.sun.jersey.api.container.ContainerException: java.io.EOFException
>>>>> at
>>>>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:346)
>>>>>
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
>>>>> at
>>>>> com.sun.grizzly.http.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:141)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:168)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:146)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:620)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:551)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:800)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.SelectorThread$1.execute(SelectorThread.java:648)
>>>>> at
>>>>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>>>>>
>>>>> at
>>>>> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>>>>> Caused by: com.sun.jersey.api.container.ContainerException:
>>>>> java.io.EOFException
>>>>> at
>>>>> com.sun.jersey.api.container.filter.GZIPContentEncodingFilter.filter(GZIPContentEncodingFilter.java:73)
>>>>>
>>>>> at
>>>>> com.sun.jersey.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:720)
>>>>>
>>>>> at
>>>>> com.sun.jersey.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:692)
>>>>>
>>>>> at
>>>>> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:344)
>>>>>
>>>>> ... 15 more
>>>>> Caused by: java.io.EOFException
>>>>> at
>>>>> java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:207)
>>>>> at
>>>>> java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:197)
>>>>> at
>>>>> java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:136)
>>>>> at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:58)
>>>>> at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:68)
>>>>> at
>>>>> com.sun.jersey.api.container.filter.GZIPContentEncodingFilter.filter(GZIPContentEncodingFilter.java:70)
>>>>>
>>>>>
>>>>> With best regards,
>>>>> Arman
>>>>>
>>>>>
>>>>> Paul Sandoz wrote:
>>>>>> Hi Arman,
>>>>>> I am cross posting to the Grizzly users list, as it might a config
>>>>>> issue with the compression set up, or it might be that the
>>>>>> compression set up is for transport encoding rather than content
>>>>>> encoding.
>>>>>> Jersey also has a content encoding filter:
>>>>>> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/container/filter/GZIPContentEncodingFilter.html
>>>>>> Paul.
>>>>>> On Jul 7, 2009, at 11:21 AM, Arman Djusupov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am testing REST interop between WCF and Jersey + standalone
>>>>>>> Grizzly server. Up to now everything works fine, except of
>>>>>>> compression which for some reason is not being applied despite
>>>>>>> having enabled it.
>>>>>>>
>>>>>>> I have initialized the standalone Grizzly in the following manner:
>>>>>>>
>>>>>>> System.out.println("Starting grizzly...");
>>>>>>> SelectorThread threadSelector = GrizzlyWebContainerFactory.create(
>>>>>>> baseUri, initParams);
>>>>>>> threadSelector.setCompression("on");
>>>>>>>
>>>>>>> threadSelector.setCompressableMimeTypes("application/fastinfoset");
>>>>>>> threadSelector.setCompressionMinSize(0);
>>>>>>>
>>>>>>> System.out.println(String.format(
>>>>>>> "Jersey app started with WADL available at
>>>>>>> %sapplication.wadl\n” + “Try out %shelloworld\nHit enter to stop
>>>>>>> it...", baseUri, baseUri));
>>>>>>> System.in.read();
>>>>>>>
>>>>>>> The client sends a request with the following header:
>>>>>>>
>>>>>>> GET /tickhistory/?count=1000 HTTP/1.1
>>>>>>> VsDebuggerCausalityData:
>>>>>>> uIDPo8NPV7XwO0VGi6Vqcn5L7qcAAAAAHgkpNDHfjEGQyOWxx+Y5qyGawiJz7CdKr295EfxJus8ACQAA
>>>>>>>
>>>>>>> Accept-Encoding: gzip,deflate
>>>>>>> Accept: application/fastinfoset,application/xml; charset=utf-8
>>>>>>> Content-Type: application/fastinfoset
>>>>>>> Host: 192.168.1.22:9998
>>>>>>>
>>>>>>> Grizzly replies using "application/fastinfoset" as it should (I
>>>>>>> am using Fast Infoset as message encoding) but it does not
>>>>>>> compress the traffic:
>>>>>>>
>>>>>>> HTTP/1.1 200 OK
>>>>>>> server: grizzly/1.7
>>>>>>> Content-Type: application/fastinfoset
>>>>>>> Date: Fri, 03 Jul 2009 15:05:37 GMT
>>>>>>> Content-Length: 7961
>>>>>>>
>>>>>>> Do you have any idea how can I enable compression? Or is it not
>>>>>>> supported yet?
>>>>>>>
>>>>>>> With best regards,
>>>>>>> Arman
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>> <request.gz>---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>