Using a non-standard HTTP method in HttpURLConnection

[Cameron McCormack]

Hi.

I want to use HttpURLConnection to send a request that uses a method
that's not defined in RFC 2616 (e.g. WebDAV's PROPFIND).
HttpURLConnection doesn't allow setting the request method to anything
other than that ones in RFC 2616 (except for CONNECT), so I'd like to
know if there is a common workaround for this that people use. I'd
really like to avoid having to write an HTTP client implementation (or
use someone else's) just because the JDK API refuses this.

Thanks,

Cameron

 

[Kevin McMurtrie]

Hi.

I want to use HttpURLConnection to send a request that uses a method
that's not defined in RFC 2616 (e.g. WebDAV's PROPFIND).
HttpURLConnection doesn't allow setting the request method to anything
other than that ones in RFC 2616 (except for CONNECT), so I'd like to
know if there is a common workaround for this that people use. I'd
really like to avoid having to write an HTTP client implementation (or
use someone else's) just because the JDK API refuses this.

Thanks,

Cameron

I'm using Innovation's HTTPClient. It's ancient but it's much easier to
use and maintain than Sun's or Apache's client. There are only a few
bugs to fix - stop() deadlocks the pipeline multiplexors and
readResponseData() doesn't build the buffer correctly.

 

[Cameron McCormack]

Hi Kevin.

I'm using Innovation's HTTPClient. It's ancient but it's much easier to
use and maintain than Sun's or Apache's client. There are only a few
bugs to fix - stop() deadlocks the pipeline multiplexors and
readResponseData() doesn't build the buffer correctly.

Thanks for the pointer. Unfortunately, HTTPClient is LGPL, which is
unusable in my situation. I may end up using the Jakarta Commons one,
but I would much rather find a solution that uses Sun's one included in
the JRE, if at all possible.

 

[Cameron McCormack]

What is the sticking point with LGPL?

The ASF has a (proposed, but currently de facto) policy of not
distributing LGPL code:

http://people.apache.org/~rubys/3party.html

 

[Arne Vajhøj]

The ASF has a (proposed, but currently de facto) policy of not
distributing LGPL code:

http://people.apache.org/~rubys/3party.html

It is Apache policy to allow users to modify their code
and distribute the modified version as closed source.
And some companies including IBM utilize that opportunity.

LGPL is not compatible with that.

But if you are working on an Apache project, then you
should be adding the missing functionality to the Jakarta
HttpClient.

For most other people it does not matter.

Arne

 

[Cameron McCormack]

So your project is an Apache project?

Yes.

 

[Arved Sandstrom]

Only a lawyer would need to disclaim legal advice. A non-lawyer can give
legal advice with impunity, if done casually without making any claims to
expertise or a business context that would require a lawyer. In a Java
newsgroup, one should assume non-lawyerness absent a claim to the
contrary. Thus, "IANAL" is a delightfully superfluous disclaimer.

The distinction between "advice" and "information" applies in many other
fields also - medicine, engineering, and even IT technical support. The
general rule (mentioned in this article:
http://www.ajs.org/prose/pro_greacen.asp, entitled "Legal information vs.
legal advice") is to never use the word "should" or respond to a question
containing that word, unless you're a lawyer, doctor, engineer (real
engineer, that is)...or in the case of IT tech support, you're within your
organisation's support guidelines.

As the above link indicates, if a person asks "how do I sue my employer?"
feel free to provide information. But if they ask "should I sue my
employer?", steer clear and refer 'em to a lawyer.

As an IT tech support example: if a person asks "how do I format my hard
drive?", tell them how. But if they ask "should I re-format my hard drive?",
send them to a good PC tech unless you want to lose their goodwill.

Wrt the LGPL, I'm thinking your biggest problem could be finding a lawyer
that could understand it. In some geographical areas that presumably is no
major issue, but in my area I doubt I'd find any lawyer that wouldn't have
to be coached through the license in detail.

AHS

 

[Daniel Pitts]

People dispense advice all the time. If I ask Aunt Sadie if I should
sue my employer, knowing that she's been a cake decorator all her life
and wouldn't know a /habeas/ from a /corpus/, and she tells me that I
should, I have no recourse against her.

Dispense all the legal advice you want, you non-lawyers. I advise you
to do so. All of you should give legal advice freely. It will not
redound to you.

Is that true in all jurisdictions though? I think the IANAL is a good
disclaimer, even if its not legally necessary. Its being good citizen
to let others know that you have an opinion, and that its not a
"professional" opinion.

 

[Arne Vajhøj]

The distinction between "advice" and "information" applies in many other
fields also - medicine, engineering, and even IT technical support. The
general rule (mentioned in this article:
http://www.ajs.org/prose/pro_greacen.asp, entitled "Legal information vs.
legal advice") is to never use the word "should" or respond to a question
containing that word, unless you're a lawyer, doctor, engineer (real
engineer, that is)...or in the case of IT tech support, you're within your
organisation's support guidelines.

As the above link indicates, if a person asks "how do I sue my employer?"
feel free to provide information. But if they ask "should I sue my
employer?", steer clear and refer 'em to a lawyer.

As an IT tech support example: if a person asks "how do I format my hard
drive?", tell them how. But if they ask "should I re-format my hard drive?",
send them to a good PC tech unless you want to lose their goodwill.

Well - I am not a lawyer.



But it should be obvious that any advice obtained from usenet is not
guaranteed in any way to be correct. In theory the reply could come
from a monkey hammering a keyboard.

I have used usenet for almost 20 years. And I consider all usenet
posts to contain an implicit disclaimer. And readers should act
accordingly.

Arne

 

[Arne Vajhøj]

Is that true in all jurisdictions though? I think the IANAL is a good
disclaimer, even if its not legally necessary. Its being good citizen
to let others know that you have an opinion, and that its not a
"professional" opinion.

I would only put in such a disclaimer when it is not obvious from
the context that "free advice from usenet is worth every cent paid".

I sometimes put it in when giving people advice on software licenses,
because in that case I want to distinguish sharply between
programmer advice and real legal advice. But besides that never.

Arne

 

[Arne Vajhøj]

But in the specific case of an LGPL-ed Java jar file, I believe there's
no problem shipping it as part of a closed-source app.

True.

But one of the keywords above is *modified version*. LGPL
prohibits that. Apache/BSD licenses does not.

There are
complications within the LGPL wrt static linking, but class-loading is
considered a dynamic link and thus those issues don't arise.

AFAIK then LGPL does not have problems with static linking - that is
GPL. And again AFAIK then GPL does not distinguish between static and
dynamic linking.

SUN seems to agree with that interpretation since the Java library is
open sourced under GPL with classpath exception - that exception would
not be necesarry if dynamic linking was OK.

Arne

 

[Arne Vajhøj]

There is a theory in jurisprudence called "contributory negligence",
i.e., that if you do something dumb, and you reasonably can be expected
to know that it was dumb, you cannot assert (as much) liability on
others' part.

Also, for there to be a tort, there must be harm to the plaintiff
arising from the defendant's actions, and there must be reason for the
plaintiff to expect competence from the advisor. I expect that without
a consideration to the advisor, and asking legal advice of programmers
in a programming forum, the recipient of that advice would have no basis
for a tort claim arising from it.

US law ?

There are probably readers from about 100 other jurisdictions.

But I hope that they all recognize that usenet posts, wikipedia,
blogs etc. are not, has never been and will never be an authoritative
source for important decisions.

Arne

 

[Kevin McMurtrie]

Yes.

I suppose you could fix Apache's then. Did they ever get PUT to work as
a lightly buffered OutputStream for HTTP 1.1? That's actually why I
selected Innovation's client a while back. Apache's and Sun's POST and
PUT could not work with a large non-seekable stream of data.

 

[Arved Sandstrom]

Well - I am not a lawyer.



But it should be obvious that any advice obtained from usenet is not
guaranteed in any way to be correct. In theory the reply could come
from a monkey hammering a keyboard.

I have used usenet for almost 20 years. And I consider all usenet
posts to contain an implicit disclaimer. And readers should act
accordingly.

Arne

I agree - in general - that there is an implicit disclaimer in Usenet posts.
And that advice obtained from Usenet is not guaranteed to be correct
(although no advice is guaranteed to be correct; a lawyer sitting in his
office can equally well steer you down the wrong path).

The point I was making is that disclaimers, whether implicit or explicit,
are all well and good, but in real life your perceived expertise with
respect to a given subject may (should) be a factor in your readiness to
offer advice. This especially holds true if your expertise is related to
your profession or job. You may be legally insulated from repercussions, but
in practical terms you may hurt your reputation, career and working/personal
relationships.

For example, if you're an acknowledged guru on subject X (decades of
experience, currently employed by an industry powerhouse as one of their
technology experts, author of reams of books on the topic, invited speaker
umpteen times) you probably don't casually dispense advice anymore, because
disclaimers from you don't really carry that much weight. Legally most of
the time, sure, but not in real life. I'll bet Josh Bloch doesn't easily get
away with "Well, I myself would do this, but hey, don't listen to me, what
do I know?" In fact, the more expertise you have, the more likely you are to
provide information, not advice. Except for when you are called upon,
typically in your professional role, to actually offer advice.

AHS

 

[Arved Sandstrom]

[ SNIP ]

But I hope that they all recognize that usenet posts, wikipedia,
blogs etc. are not, has never been and will never be an authoritative
source for important decisions.

Arne

It would be nice if that were so. In real life people will look at who wrote
the Usenet post or blog or Web article. If Michael Kay happens to write
something about XSLT it's going to be pretty authoritative.

Depending on the newsgroup or mailing list I myself sure could see using
some posts or replies as being authoritative sources for important
decisions. Again, it depends on your knowledge of the authors.

AHS

 

[Arne Vajhøj]

[ SNIP ]

But I hope that they all recognize that usenet posts, wikipedia,
blogs etc. are not, has never been and will never be an authoritative
source for important decisions.

It would be nice if that were so. In real life people will look at who wrote
the Usenet post or blog or Web article. If Michael Kay happens to write
something about XSLT it's going to be pretty authoritative.

Depending on the newsgroup or mailing list I myself sure could see using
some posts or replies as being authoritative sources for important
decisions. Again, it depends on your knowledge of the authors.

Even with respected authors then one should remember the context. It is
not guaranteed that the author spend much time investigating the
problem.

If some guru writes X on the internet then X should not be taken
as a professional advice you would get if you paid him big money
as a consultant.

It would definitely be smart to put X on the top of the "to be
investigated" list though.

Arne