> I do wonder if this is suitably rigorous however? My original
> suggestion allows the duplicate header _providing_ that the values
> are the same, whereas the solution you provide just takes the first
> value for content-length.
Adrian, as I mentioned, your solution was fine, but the problem is
that I'd like to avoid changing the original/default MimeHeaders logic.
The solution I've proposed doesn't change the default logic, so people
which relied on original MimeHeader logic will not be affected. On
other hand with that fix you can implement your own logic to process
content-length header.
You don't have to use the code I've sent, I just wanted to show how
you can change the original getContentLength logic, that's it.
> In any case, once 1.9.19 is made available, I will switch to your
> solution.
Ok.
Thanks.
WBR,
Alexey.
>
> Regards,
>
>
> Adrian Smith
> BT Design
>
> -----Original Message-----
> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> Sent: 09 December 2009 15:11
> To: users_at_grizzly.dev.java.net
> Cc: Cloud Dev G
> Subject: Re: Duplicate Content-Length headers
>
> Adrian, I've fixed this in 1.9.19-SNAPSHOT branch (trunk).
> Artifacts were not uploaded to maven repo, but you can checkout
> grizzly sources and build them locally to test.
> With the fix you'll be able to change HTTP Request logic and allow
> content-length duplication like:
>
> selectorThread.setProcessorTaskFactory(new
> ProcessorTaskFactory() {
>
> public ProcessorTask createProcessorTask(SelectorThread
> selectorThread, boolean isInitialize) {
> return new ProcessorTask(isInitialize,
> selectorThread.getBufferResponse()) {
>
> @Override
> protected Request createRequest() {
> return new Request() {
>
> @Override
> public long getContentLengthLong() {
> if (contentLength > -1) {
> return contentLength;
> }
>
> MessageBytes clB =
> getMimeHeaders().getValue("content-length");
> contentLength = (clB == null ||
> clB.isNull()) ? -1 : clB.getLong();
>
> return contentLength;
> }
>
> };
> }
>
> };
> }
> });
>
>
> On Dec 9, 2009, at 15:37 , adrian.p.smith_at_bt.com wrote:
>
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=766
>>
>>
>> -----Original Message-----
>> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
>> Sent: 09 December 2009 14:28
>> To: users_at_grizzly.dev.java.net
>> Subject: Re: Duplicate Content-Length headers
>>
>> Hi Adrian,
>>
>> can I ask you to fill an issue on Grizzly issuetracker?
>> Your fix will work, but not sure we want to make this behavior
>> default. I'll rather add some extension points, which will let you
>> have this behavior on demand. So existing applications will not be
>> affected.
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>> On Dec 9, 2009, at 12:11 , adrian.p.smith_at_bt.com wrote:
>>
>>> I am using Grizzly embedded in Spring as a server for Jersey, so my
>>> code
>>> is not easily used standalone:
>>>
>>>
>>>
>>> System
>>> .setProperty("com.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLAS
>>> H", "true");
>>> IoCComponentProviderFactory ioCComponentProviderFactory =
>>> new SpringComponentProviderFactory(this.resourceConfig,
>>> (ConfigurableApplicationContext) this.applicationContext);
>>> server =
>>> GrizzlyServerFactory.create(String.format("http://localhost:%s/",
>>> this.port), resourceConfig, ioCComponentProviderFactory);
>>>
>>> However, I guess you guys know the most simple way to spin up a
>>> Grizzly?!
>>>
>>> BTW, I have a working fix for the problem:
>>>
>>>
>>> public MessageBytes getUniqueValue(String name) {
>>> MessageBytes result = null;
>>> for (int i = 0; i < count; i++) {
>>> if (headers[i].getName().equalsIgnoreCase(name)) {
>>> if (result == null) {
>>> result = headers[i].getValue();
>>> } else {
>>> if (! result.equals(headers[i].getValue())) {
>>> throw new IllegalArgumentException();
>>> }
>>> }
>>> }
>>> }
>>> return result;
>>> }
>>>
>>>
>>> Regards,
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
>>> Sent: 09 December 2009 10:22
>>> To: users_at_grizzly.dev.java.net
>>> Subject: Re: Duplicate Content-Length headers
>>>
>>> Hi Adrian,
>>>
>>> can you pls. show Grizzly initialization code?
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>> On Dec 8, 2009, at 11:20 , adrian.p.smith_at_bt.com wrote:
>>>
>>>> Hubert,
>>>>
>>>> Here is a simple unit test to run against a running server.
>>>>
>>>> @Test
>>>> public void testDoubleContentLengthHeaders() throws Exception {
>>>> HttpClient httpClient = new HttpClient();
>>>> PutMethod putMethod = new PutMethod("http://localhost:9090");
>>>> putMethod.addRequestHeader("Content-Length", "0");
>>>> putMethod.addRequestHeader("content-length", "0");
>>>>
>>>> int rc = httpClient.executeMethod(putMethod);
>>>> System.out.println(rc);
>>>>
>>>> assertFalse(400 == rc);
>>>> }
>>>>
>>>> I think the Grizzly code in question is somewhere around
>>>> com.sun.grizzly.util.http.MimeHeaders.java
>>>>
>>>> /**
>>>> * Finds and returns a unique header field with the given name. If
>>>> no such
>>>> * field exists, null is returned. If the specified header field is
>>>> not
>>>> * unique then an {_at_link IllegalArgumentException} is thrown.
>>>> */
>>>> public MessageBytes getUniqueValue(String name) {
>>>> MessageBytes result = null;
>>>> for (int i = 0; i < count; i++) {
>>>> if (headers[i].getName().equalsIgnoreCase(name)) {
>>>> if (result == null) {
>>>> result = headers[i].getValue();
>>>> } else {
>>>> throw new IllegalArgumentException();
>>>> }
>>>> }
>>>> }
>>>> return result;
>>>> }
>>>>
>>>>
>>>> Which results in a 400 BAD_REQUEST response?
>>>>
>>>> Does this make sense?
>>>>
>>>> Regards,
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Hubert Iwaniuk [mailto:neotyk_at_kungfoo.pl]
>>>> Sent: 08 December 2009 09:32
>>>> To: users_at_grizzly.dev.java.net
>>>> Subject: Re: Duplicate Content-Length headers
>>>>
>>>> Hi Adrian,
>>>>
>>>> Can you provide a sample to reproduce this issue.
>>>>
>>>> Thanks,
>>>> Hubert
>>>>
>>>>
>>>>
>>>> On Tue, Dec 8, 2009 at 9:36 AM, <adrian.p.smith_at_bt.com> wrote:
>>>>> I notice that Grizzly rejects requests with more than one
>>>> Content-Length
>>>>>
>>>>> header.
>>>>>
>>>>>
>>>>>
>>>>> I understand why this is done, but could the team consider an
>>>>>
>>>>> alternative strategy?
>>>>>
>>>>>
>>>>>
>>>>> Could the server be made to accept these requests, providing the
>>>> values
>>>>>
>>>>> for content-length are identical?
>>>>>
>>>>>
>>>>>
>>>>> I have some legacy clients that I cannot change and this is making
>>>>> it
>>>>>
>>>>> hard for me to choose Grizzly as my prefered server.
>>>>>
>>>>>
>>>>>
>>>>> TIA.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>