Build failed in Hudson: 3.0-i386-OpenBSD-4.5 #44

See -- Started by upstream project "3.0-amd64-CentOS-5.3" build number 56 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.0-i386-OpenBSD-4.5 #43

See -- Started by upstream project "3.0-amd64-CentOS-5.3" build number 55 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.0-i386-OpenBSD-4.5 #42

See -- Started by upstream project "3.0-amd64-CentOS-5.3" build number 54 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.1-i386-OpenBSD-4.5 #68

See -- Started by upstream project "3.1-amd64-CentOS-5.3" build number 102 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.1-i386-OpenBSD-4.5 #67

See -- Started by upstream project "3.1-amd64-CentOS-5.3" build number 101 Building remotely on vobsd ERROR: Failed to pull

Hudson build is back to normal: 3.HEAD-i386-opensolaris #146

See

Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #262

See -- Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 387 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.HEAD-i386-opensolaris #145

See Changes: [Henrik Nordstrom ] Fix stale=true on digest requests with unknown nonce The nonce staleness check only worked if the stale nonce had not yet been garbage collected, often resulting in incorrect stale=false resp

Re: "negotiate" auth with fallback to other schemes

Livio B wrote: Hi, In particular, if I want only transparent auth, it wouldn't make sense to retry the authentication because either the helper would get the same SSO (denied) credentials or the user would get prompted (which I don't want). On a different scenario, where it is ok to prompt the

Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #261

See -- Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 386 Building remotely on vobsd ERROR: Failed to pull

[patch] authFixHeader and failed requests

While investigating why digest auth wrongly indicated stale=false on unknown nonces even when all the logics for fixing that has been forwardported since way back I stumbled across this little difference between Squid-2 & Squid-3 in how they fix up auth headers on failed auth requests. In Squid-2 t

Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #260

See -- Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 385 Building remotely on vobsd ERROR: Failed to pull

Re: "negotiate" auth with fallback to other schemes

"Livio B" wrote in message news:31f0d2c51003050619o6d3a78b9uaf319d8e63aa7...@mail.gmail.com... Hi, In particular, if I want only transparent auth, it wouldn't make sense to retry the authentication because either the helper would get the same SSO (denied) credentials or the user would get pr

Re: "negotiate" auth with fallback to other schemes

Hi, >> In particular, if I want only transparent auth, it wouldn't make sense >> to retry the authentication because either the helper would get the >> same SSO (denied) credentials or the user would get prompted (which I >> don't want). On a different scenario, where it is ok to prompt the >> use

Re: [PATCH] HTTP/1.1 to servers

Henrik Nordstrom wrote: fre 2010-03-05 klockan 23:08 +1300 skrev Amos Jeffries: Sending HTTP/1.1 in all version details sent to peers and servers. Passes the basic tests I've thrown at it. If anyone can think of some please do. The src/client_side.cc change looks wrong to me.. should not ove

Re: [PATCH] HTTP/1.1 to servers

fre 2010-03-05 klockan 23:08 +1300 skrev Amos Jeffries: > Sending HTTP/1.1 in all version details sent to peers and servers. > > Passes the basic tests I've thrown at it. If anyone can think of some > please do. The src/client_side.cc change looks wrong to me.. should not overwrite the version s

Re: [REVIEW] Carefully verify digest responses

tor 2010-03-04 klockan 20:57 -0700 skrev Alex Rousskov: > Please consider adding a cppunit test to check a few common and corner > parsing cases. Unfortunately the existing auth tests we have do not come close to touching actual request parsing/handling, and trying to get things in shape to the l

Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #259

See -- Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 384 Building remotely on vobsd ERROR: Failed to pull

Hudson build is back to normal: 3.HEAD-amd64-CentOS-5.3 #384

See

Build failed in Hudson: 3.1-i386-OpenBSD-4.5 #66

See -- Started by upstream project "3.1-amd64-CentOS-5.3" build number 100 Building remotely on vobsd ERROR: Failed to pull

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #383

See Changes: [Francesco Chemolli ] Raised the debug-level of one cache manager related message [Francesco Chemolli ] Raised some noncritical debug messages' debug-level. -- [...trunc

[PATCH] HTTP/1.1 to servers

Sending HTTP/1.1 in all version details sent to peers and servers. Passes the basic tests I've thrown at it. If anyone can think of some please do. Amos === modified file 'src/HttpRequest.cc' --- src/HttpRequest.cc 2010-02-25 23:00:39 + +++ src/HttpRequest.cc 2010-03-05 08:18:24 + @@ -

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #382

See Changes: [Francesco Chemolli ] Raised some noncritical debug messages' debug-level. [Amos Jeffries ] Send HTTP1.1 compliant 417 responses Port of the 417 response handling and associated ignore_expect_100 from Squid 2.7

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #381

See Changes: [Amos Jeffries ] Send HTTP1.1 compliant 417 responses Port of the 417 response handling and associated ignore_expect_100 from Squid 2.7. [Amos Jeffries ] Rationalize the default httpd_accel_surrogate_id Preven