I don't think he was asking about the spec's facilities for request requirement discovery, I think he was suggesting that the httpclient's state mechanism should behave more like a conventional browsers'. There's no reason not to do it; even if you could count on all of your servers to implement the response code 100 heuristics, there's nothing wrong with the standard browser behavior.
On Tue, 29 Jan 2002, David Bullock wrote: > I was reading in the HTTP 1.1 spec just today, and found that there is a > way for the client to see if the server is willing to respond to the > HTTP request headers before sending the message body. > > If the server is, then it gives the response right away. If not, then > it asks the client to continue ( HTTP response code 100 ) with the > message body. This allows for things like security credential exchanges, > redirects, etc, to be performed without incurring unnecessary network > overhead. > > This is probably exactly what you're after to limit transmitting a large > body twice. > > Details are at: > > ftp://ftp.isi.edu/in-notes/rfc2616.txt > > Section 8.2.3 > > > cheers, > David. > > > On Thu, 17 Jan 2002, Matthew Albright wrote: > > > I've run into a interesting little shortcoming with HttpClient, and > > would like to know if someone is working on a solution. > > > > When a browser goes to a site that requires Basic Authentication, it > > will make a request (GET /), get a 401 response with a realm > > attached, and prompt the user for a username and password for that > > realm. After getting the username/password, it fills in the > > appropriate header with that information, and makes the request > > again, gets the 200 response, and presumably all the data for the > > page. > > > > Now, on subsequent visits to the same site, it appears (from server > > logs) that the browser fills in the Authentication header for each > > request, in a kind of pre-emptive strike. That way, the browser and > > server don't have to do the request-401-auth-200 dance every single > > time. > > > > It appears that HttpClient doesn't do this process exactly like a > > browser. Every single Method that is execute()'d will send out the > > initial request without Authentication, get the 401, and then send > > the request again with authentication information attached. > > > > This is not normally a problem, or even noticable. > > > > My problem is that I'm doing an HTTP POST with a good amount of data. > > This data is being sent down the wire twice for every > > Method.execute() that I'm calling. I'm on DSL, so it's not too bad, > > but for large payloads or slow connections, it's IMHO unacceptable. > > > > I'm considering modifying HttpState and HttpMethodBase to act more > > like a browser... make HttpState store not only the realm, but also > > the url of the site that requires authentication, and then make > > HttpMethodBase fill in that information if it matches for every > > request after the first successful one. > > > > Is anyone else working on this, or have any input on a specific > > approach to this problem? Any things I should look out for? Does > > anyone have any idea what I'm talking about? ;) > > > > And, once I've finished this, and gotten it working, what should I do > > with it? Just send a patch to this list? > > > > Thanks for reading this far. > > > > matt > > > > > > __________________________________________________ > > Do You Yahoo!? > > Send FREE video emails in Yahoo! Mail! > > http://promo.yahoo.com/videomail/ > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > cheers, -Ian -- Ian Kallen <[EMAIL PROTECTED]> | AIM/yahoo: iankallen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
