Julian Reschke | 2 Oct 10:58 2011
Picon
Picon

Re: [#95] Multiple Content-Lengths

On 2010-10-13 22:57, William Chan (陈智昌) wrote:
> First bug report wrt to this change:
> http://code.google.com/p/chromium/issues/detail?id=59077.  Indeed, this
> is a duplicate Content-Length (not mismatching).
> ...

So it seems that due this type of bug reports, Chrome loosened the check 
to allow multiple instances when the values are identical (which is 
explicitly allowed in HTTPbis per the resolution of #95).

Furthermore, Firefox 7 is now doing similar checks, but adds more header 
fields (Location, Content-Disposition), and also has started to be picky 
about certain field values (such as C-L with a broken integer).

This is good. I'd like to thank the implementers that they were willing 
to "break" a few pages and deal with the bug reports, in order to make 
this improvement!

Best regards, Julian

William Chan (陈智昌 | 2 Oct 23:44 2011

Re: [#95] Multiple Content-Lengths

On Sun, Oct 2, 2011 at 1:58 AM, Julian Reschke <julian.reschke-Mmb7MZpHnFY@public.gmane.org> wrote:

On 2010-10-13 22:57, William Chan (陈智昌) wrote:
First bug report wrt to this change:
http://code.google.com/p/chromium/issues/detail?id=59077.  Indeed, this
is a duplicate Content-Length (not mismatching).
...

So it seems that due this type of bug reports, Chrome loosened the check to allow multiple instances when the values are identical (which is explicitly allowed in HTTPbis per the resolution of #95).

Furthermore, Firefox 7 is now doing similar checks, but adds more header fields (Location, Content-Disposition), and also has started to be picky about certain field values (such as C-L with a broken integer).

Can you explain this checks in more detail so I can see if we want to add them to Chrome? Or better yet, file a bug report at new.crbug.com.
 

This is good. I'd like to thank the implementers that they were willing to "break" a few pages and deal with the bug reports, in order to make this improvement!

Also note http://code.google.com/p/chromium/issues/detail?id=71802. HughesNet seems to be injecting bogus CONTENT-LENGTH strings in the response. I believe I've heard of this happening at least 3 times, all with HughesNet.


Best regards, Julian

Dang Van | 3 Oct 10:11 2011
Picon

Invitation to connect on LinkedIn

 
 
 
 
From Dang Van
 
Domestic women at Reee
Montreal, Canada Area
 
 
 

HTTP,

I'd like to add you to my professional network on LinkedIn.

- Dang

 
 
 
 
 
 
You are receiving Invitation to Connect emails. Unsubscribe
© 2011, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA
 
Dang Van | 3 Oct 18:48 2011
Picon

Invitation to connect on LinkedIn

 
 
 
 
From Dang Van
 
Domestic women at Reee
Montreal, Canada Area
 
 
 

HTTP,

I'd like to add you to my professional network on LinkedIn.

- Dang

 
 
 
 
 
 
You are receiving Invitation to Connect emails. Unsubscribe
© 2011, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA
 
Yutaka OIWA | 4 Oct 11:02 2011
Picon

Re: OT re HTTP auth disassocation of credentials

Dear all,
(added http-auth mailing list, responses preferred to this list)

recently some browser vendors are trying incorporating authentication
control with the browser's identity management mechanisms, and they
propose some HTML/JavaScript level extensions for it.
If you just need log-out feature, and if you can assume JavaScript support,
it may just work for you.  I think this trend may allow us a small icon
for authentication control, hopefully.

I am working from a bit different viewpoint, making HTTP authentication
support more features which is currently only available via Form-based
authentications, not limited to log-out control.
My proposal is currently in a part of my new HTTP authentication scheme
draft (draft-oiwa-http-mutualauth-09), and I am planning to make it
a separate draft in the next revision.

I put "pre-draft" on our Web page at

<https://www.rcis.aist.go.jp/special/MutualAuth/files/spec/draft-oiwa-http-auth-extension-pre00.4.txt>

(or < https://bit.ly/o3MDq4 > if line wrapping is nasty), and I will submit -00
draft possibly before the Taiwan meeting.
Again, it may be over-engineered for log-out only, but please have a look,
and if you're going to or wish to extend HTTP, it may serve for your needs.

On 09/20/11 06:28, Adrien de Croy wrote:
> 
> I think it would me more useful if it could be controlled from the server. 
> Hence a status or header.
> 
> However, for browser vendors, since finding screen real-estate is such a
> problem, an approach could be taken similar to the one used to show that a
> sight is using TLS and to see certificate information.  E.g. a small icon
> showing that the request is authenticated, which could then give details of the
> method, and an option to log out.
> 
> Adrien
> 
> 
> On 20/09/2011 12:43 a.m., Karl Dubost wrote:
>> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
>>> FWIW I'd rather see browsers put a logout-button right in the browser GUI.
>>> The button could simply cause the browser to stop sending the credentials.
>>
>> As much as I could see the benefit for it. I do not think this will fly for
>> browser vendors. They are all currently trying to simplify the UI and
>> minimize it. There is also the balance in between introducing a new UI
>> feature with the number of times this (HTTP Auth) will be used. For example,
>> Firefox removed the RSS icon (by default).
>>
>> PS: not advocating for any sides of the issue.
>>
> 
Adrien de Croy | 5 Oct 11:16 2011

Proxy-Authorization with empty credentials


Hi all, I'm hoping someone can help here.

I've been trawling RFC2616 and 2617 for clarity on an issue a customer 
is having.

They have an AV product that does updates using HTTP, and has 
configuration settings for a proxy, and settings to enable/disable proxy 
auth and supply credentials.

The problem is the software sends Proxy-Authorization in all requests, 
using Basic, and no user/pass - just a base64 encoded ':'

Since the credentials are empty, we fail authorization, even though 
policy didn't require authorization, the existence of the 
Proxy-Authorization header in the request triggered our auth code.

The reason we go straight into our auth code on the existence of this 
header, is because with Basic auth, the client will commonly re-use the 
credentials it previously successfully validated, and going straight to 
check the creds saves a 407 and round trip.

I'm struggling to find any language in 2616 and 2617 that states that a 
Proxy-Authorization with empty creds is invalid, although it seems like 
an incredibly bad idea.

The customer contacted the vendor of the offending software, and they 
said it's by design and not considered a bug.

Maybe we need to clarify this going forward?  I think a client shouldn't 
send P-A unless they wish to authenticate, and shouldn't send Basic 
creds without clear directive from the user (since it's a potential 
credential leak).

Adrien

--

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Andreas Petersson | 5 Oct 12:33 2011
Picon

I-D draft-petersson-forwarded-for-01.txt

Hi.

The draft for the forwarded-for is finally updated. The main
revision is the extension of scope for the draft by adding a 
parametrized list.

http://www.ietf.org/id/draft-petersson-forwarded-for-01.txt

Please comment.

Best regards,
 Andreas Petersson, 
 Opera Software

Poul-Henning Kamp | 5 Oct 12:38 2011
Picon

Re: I-D draft-petersson-forwarded-for-01.txt

In message <20111005123338.320c38d4 <at> hetzer>, Andreas Petersson writes:

>http://www.ietf.org/id/draft-petersson-forwarded-for-01.txt
>
>Please comment.

]       proto-kv   = "proto=" ( "http" | "https" )

Given Speedy, Websockets and other such experiments, shouldn't this
allow any protocol-name ?

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Andreas Petersson | 5 Oct 20:12 2011
Picon

Re: I-D draft-petersson-forwarded-for-01.txt

On 10/5/11 12:38 PM, Poul-Henning Kamp wrote:
> In message <20111005123338.320c38d4 <at> hetzer>, Andreas Petersson writes:
> 
>> http://www.ietf.org/id/draft-petersson-forwarded-for-01.txt
>>
>> Please comment.
> 
> ]       proto-kv   = "proto=" ( "http" | "https" )
> 
> Given Speedy, Websockets and other such experiments, shouldn't this
> allow any protocol-name ?
> 

Yes, I guess that sounds quite reasonable. But will every protocol
always only have one unique name, that everyone would use, without need
for discussion?

Another, perhaps a non-issue, would be name changes (somewhat like
jabber vs. xmpp or yp vs. nis).

/Andreas Petersson

Poul-Henning Kamp | 5 Oct 22:03 2011
Picon

Re: I-D draft-petersson-forwarded-for-01.txt

In message <4E8C9DFD.2090908@...>, Andreas Petersson writes:

>> ]       proto-kv   = "proto=" ( "http" | "https" )
>> 
>> Given Speedy, Websockets and other such experiments, shouldn't this
>> allow any protocol-name ?
>
>Yes, I guess that sounds quite reasonable. But will every protocol
>always only have one unique name, that everyone would use, without need
>for discussion?

We're not here to solve _all_ the worlds problems :-)

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


Gmane