On Jul 13, 2009, at 3:56 PM, Arman Djusupov wrote:
> 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.
>
OK.
I wonder if Grizzly/GF does or could support an automatic sending of
the 100 status under the covers of the application ?
Paul.
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>