cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John McNair (JIRA)" <>
Subject [jira] [Updated] (CXF-6330) HTTPConduit does not enforce configuration constraints
Date Sat, 04 Apr 2015 04:37:33 GMT


John McNair updated CXF-6330:
    Attachment: cxf-http-client-policy-bug.tar.gz

This is a simple project with a test case demonstrating the failure.

> HTTPConduit does not enforce configuration constraints
> ------------------------------------------------------
>                 Key: CXF-6330
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 2.7.0, 3.0.4
>         Environment: Linux, Java 7
>            Reporter: John McNair
>            Priority: Minor
>              Labels: easyfix, easytest
>         Attachments: cxf-http-client-policy-bug.tar.gz
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> The documentation states that chunking cannot be used if either of these conditions are
> - http-conf:basicAuthSupplier is configured to provide credentials preemptively
> - AutoRedirect is set to true
> It further states that setAllowChunking is ignored if one of those conditions are met.
> See the docs here:
> This makes sense, so I think the intent behind the documentation is correct.  However,
it does not reflect the behavior of the code.
> If the chunking threshold is met then:
> setAutoRedirect(true), unsetAllowChunking() -> request is chunked
> setAutoRedirect(true), setAllowChunking(true) -> request is chunked
> setAutoRedirect(true), setAllowChunking(false) -> request is not chunked
> So setAllowChunking() is not ignored.
> I was intending to submit a patch, but when I started digging, it seems there are several
classes which have some level of responsibility for interpreting the values in HTTPClientPolicy.
 The most natural place to impose these restrictions would be HTTPClientPolicy so that all
consumers would share a similar behavior.  However, that class is generated.
> I'm not really sure where this should be fixed then.

This message was sent by Atlassian JIRA

View raw message