Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: HTTP and Java Date: Sat, 02 Apr 2011 16:27:21 -0400 Organization: A noiseless patient Spider Lines: 20 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 2 Apr 2011 20:27:21 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="LtjcJP1H6uHOtkcPMh0bUA"; logging-data="13681"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M2DVqBnPMDhzjfVjUqi3bkouJl/e2IxY=" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.16pre) Gecko/20110305 Lightning/1.0b3pre Thunderbird/3.1.10pre In-Reply-To: Cancel-Lock: sha1:HX5iLxlc81GcIZTnizKT5taScUE= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2772 On 04/02/2011 02:35 AM, Roedy Green wrote: > If Java sent an identical HTTP header, to that sent by a browser, > including User-Agent to a website, is there a plausible mechanism by > which a website would treat the requests differently, namely reject > Java and accept the browser request? A plausible technique is the use of separating out the real content into things which require further loading--like requiring client-side scripting, cookies, use of CSS, iframes, images, embedded plugins (e.g., Flash or Silverlight), client-side redirects. You can then ensure that these things are also downloaded before accepting other page requests. An additional factor could be if browsers actually use HTTP different from Java... e.g., if one pipelines and the other doesn't, or perhaps automatic SSL upgrading, etc. It all comes down to how many false negatives the server is willing to bear. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth