Hi David,
David Daney wrote:
Wolfgang Baer wrote:
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.
This method has nothing to do with the "version of the runtime", whatever
you mean with that. It would be called form the gnu.* namespace by a few GNU
internal classes implementing IPP.
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?
There is nothing one could determine in Sun's runtime. Printing is not
specified at all for the internals. I even don't know if SUN (it supports
CUPS since 1.5) implements a java only or native connection to cups.
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.
Thats actually what the apache commons-httpclient library does. One has
to explicitly enable the use of Expect. Thats how I found the bug/problem btw.
However, I have no clue at all in the HTTP / java.net area so I cannot
provide a patch which correctly would address such a change. Beside that,
if it would be done the same way as this patch it would also introduce a
public method in the implementation class of URLConnection to enable Expect
header usage.
Wolfgang
