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
>