Wolfgang Baer wrote:
Hi all,

Cups uses IPP over HTTP for communication. However the current cups versions don't correctly implement HTTP 1.1. In particular they fail if 'Expect: 100-continue' header is set. And thats the default in GNU classpath.

The bug is known upstream and will be fixed in CUPS 1.2.

I currently work in my local tree with an addition to Request and
HTTPURLConnection to disable 'Expect: 100-continue' on request.

2006-01-30  Wolfgang Baer  <[EMAIL PROTECTED]>

    * gnu/java/net/protocol/http/HTTPURLConnection.java:
    (disableExpect): New field.
    (disableExpectHeader): New method.
    (connect): If disableExpect is true set requestBodyNegotiationThreshold
    to -1 to diable 'Expect: 100-continue' usage.
    * gnu/java/net/protocol/http/Request.java
    (dispatch): Don't use 'Expect: 100-continue' if
requestBodyNegotiationThreshold is negative as explained in api docs. I don't know if its good to introduce a new public method which could be used
at least per reflection, as HTTPURLConnection is the GNU specific
implementation class for java.net.HttpURLConnection. The default behaviour is
not changed by this patch.

The change to Request is actually a fix to implement the behaviour as
advertised by the API documentation of the setRequestBodyNegotiationThreshold
method.

Comments, or other ideas how I can use the class without expect header ?

I don't like this approach because the basic idea behind classpath is to make a compatible implementation of the java runtime. Adding secret methods that have to be called depending on the version of the runtime seems contrary to that goal.

It is not improbable that there are bugs in this area of the HTTPURLConnection, I would prefer to try to find a deeper underlying problem rather than apply a patch that masks it.

Can you do this:

1) Emperically determine what Sun's runtime does with respect ro Expect headers. Does it work with CUPS < 1.2?

2) Would it make sense to never send an Expect header UNLESS it was explicitly set by the calling code? My reading of RFC 2616 makes me think that this is what we should do. If this makes sense submit a patch that does this.

David Daney

Reply via email to