Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-28 Thread bernhardredl
i have run hg pull and hg update on mozilla central and still have no 
LOAD_DOCUMENT_URI. But i can skip 18 if you want.

i have a first draft of my patch: (see link below)
The problem seems to be that this patch breaks the WHOLE Cookie handling of 
firefox. (at least it fixes my original sync bug ;))

Maybe someone can point me to the part where i broke cookies.
i have attached the patch here:
https://bugzilla.mozilla.org/attachment.cgi?id=719791action=diff

I also seek feedback where to put testcases and what they should cover.

-Bernhard
Am Samstag, 23. Februar 2013 03:24:33 UTC+1 schrieb Boris Zbarsky:
 On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote:
 
  const unsigned long LOAD_NOCOOKIES = 1  15;
 
  ... just stop sending / accepting cookies at this request
 
 
 
 115 is LOAD_FRESH_CONNECTION, no?
 
 
 
  const unsigned long LOAD_NOAUTH  = 1  16;
 
  ... don't add authentification headers automatically
 
 
 
 116 is LOAD_DOCUMENT_URI.
 
 
 
 So at the very least you'll need different values for these constants.
 
 
 
 -Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-28 Thread Boris Zbarsky

On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote:

i have run hg pull and hg update on mozilla central and still have no 
LOAD_DOCUMENT_URI.


Are you looking in the right file?


The problem seems to be that this patch breaks the WHOLE Cookie handling of 
firefox.


Because your LOAD_NO_COOKIES has the same value as LOAD_DOCUMENT_URI. 
Which means it's getting set for every web page load.


Oh, and your LOAD_NOAUTH_HEADER has the same value as 
LOAD_RETARGETED_DOCUMENT_URI which will lead to subtle bugs of its own, 
of course.


You really can't introduce new flags to a bitfield that have the same 
values as existing flags.   It just doesn't work well.  ;)


On a more serious note, I believe at this point all the flags except 
(125) are in use on HTTP channel, between nsIRequest, nsIChannel, and 
nsICachingChannel


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-28 Thread bernhardredl
Yep, you are right. I assumed nsIRequest would be the only file assigning these 
values.

What numbers should i choose? I need 2 flags and unsigned long only provides 32 
possibility which are already used (except 25)

For me it would be ok to just fix the cookies issue :) But i guess there is a 
reason why 25 is not used.

-Bernhard
Am Freitag, 1. März 2013 03:59:08 UTC+1 schrieb Boris Zbarsky:
 On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote:
 
  i have run hg pull and hg update on mozilla central and still have no 
  LOAD_DOCUMENT_URI.
 
 
 
 Are you looking in the right file?
 
 
 
  The problem seems to be that this patch breaks the WHOLE Cookie handling of 
  firefox.
 
 
 
 Because your LOAD_NO_COOKIES has the same value as LOAD_DOCUMENT_URI. 
 
 Which means it's getting set for every web page load.
 
 
 
 Oh, and your LOAD_NOAUTH_HEADER has the same value as 
 
 LOAD_RETARGETED_DOCUMENT_URI which will lead to subtle bugs of its own, 
 
 of course.
 
 
 
 You really can't introduce new flags to a bitfield that have the same 
 
 values as existing flags.   It just doesn't work well.  ;)
 
 
 
 On a more serious note, I believe at this point all the flags except 
 
 (125) are in use on HTTP channel, between nsIRequest, nsIChannel, and 
 
 nsICachingChannel
 
 
 
 -Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-28 Thread bernhardredl
just to keep this thread up to date. I asked jduell if it is possible to change 
long to int64_t
Am Freitag, 1. März 2013 04:11:40 UTC+1 schrieb bernha...@gmail.com:
 Yep, you are right. I assumed nsIRequest would be the only file assigning 
 these values.
 
 
 
 What numbers should i choose? I need 2 flags and unsigned long only provides 
 32 possibility which are already used (except 25)
 
 
 
 For me it would be ok to just fix the cookies issue :) But i guess there is a 
 reason why 25 is not used.
 
 
 
 -Bernhard
 
 Am Freitag, 1. März 2013 03:59:08 UTC+1 schrieb Boris Zbarsky:
 
  On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote:
 
  
 
   i have run hg pull and hg update on mozilla central and still have no 
   LOAD_DOCUMENT_URI.
 
  
 
  
 
  
 
  Are you looking in the right file?
 
  
 
  
 
  
 
   The problem seems to be that this patch breaks the WHOLE Cookie handling 
   of firefox.
 
  
 
  
 
  
 
  Because your LOAD_NO_COOKIES has the same value as LOAD_DOCUMENT_URI. 
 
  
 
  Which means it's getting set for every web page load.
 
  
 
  
 
  
 
  Oh, and your LOAD_NOAUTH_HEADER has the same value as 
 
  
 
  LOAD_RETARGETED_DOCUMENT_URI which will lead to subtle bugs of its own, 
 
  
 
  of course.
 
  
 
  
 
  
 
  You really can't introduce new flags to a bitfield that have the same 
 
  
 
  values as existing flags.   It just doesn't work well.  ;)
 
  
 
  
 
  
 
  On a more serious note, I believe at this point all the flags except 
 
  
 
  (125) are in use on HTTP channel, between nsIRequest, nsIChannel, and 
 
  
 
  nsICachingChannel
 
  
 
  
 
  
 
  -Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-28 Thread Jason Duell

On 02/28/2013 07:29 PM, bernhardr...@gmail.com wrote:

just to keep this thread up to date. I asked jduell if it is possible to change 
long to int64_t


We're going to upgrade to 64 bits in

   https://bugzilla.mozilla.org/show_bug.cgi?id=846629

Jason

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-22 Thread bernhardredl
sry for double posting this to dev-apps-firefox. got a hint that this group 
would be the better group.

hi

i'm willing to fix https://bugzilla.mozilla.org/show_bug.cgi?id=836602

Summary: The rest api should not send cookies and thus now uses the
LOAD_ANONYMOUS flag. But this flag also denies (client side)
authentication like my custom firefox sync requires.
therefore firefox sync is broken for me since = F18.

As suggested by rnewman i'm going to add more fine grain LOAD_
constants. (bug comment #13)

i'm planing to add 2 new constants:

const unsigned long LOAD_NOCOOKIES = 1  15;
.. just stop sending / accepting cookies at this request

const unsigned long LOAD_NOAUTH  = 1  16;
.. don't add authentification headers automatically

the second constant would be the fix for
https://bugzilla.mozilla.org/show_bug.cgi?id=646686

Maybe i can get some input from the Gecko folks?

-Bernhard
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-22 Thread Brian Smith
bernhardr...@gmail.com wrote:
 i'm willing to fix
 https://bugzilla.mozilla.org/show_bug.cgi?id=836602
 
 Summary: The rest api should not send cookies and thus now uses the
 LOAD_ANONYMOUS flag. But this flag also denies (client side)
 authentication like my custom firefox sync requires.
 therefore firefox sync is broken for me since = F18.

Which modes of authentication does the Sync team wish to support in the product?

Currently it supports and requires (I think) HTTP authentication without 
cookies and without SSL client certificates.

The proposal (I think) is to support SSL client certificates with HTTP 
authentication. But, if you area already doing SSL client authentication then 
do you really need HTTP authentication too? Should that mode of operation be, 
instead, SSL client authentication without HTTP authentication and without 
cookies?

How would the Sync client decide whether to use SSL client certificates or HTTP 
authentication? Would there be some new UI?

I am willing to help with things (e.g. reviewing the tests) but it is up to the 
Sync team to decide on the prioritization of the work and decide what the 
testing requirements are. IMO, writing tests for this will be difficult as 
there's no framework for SSL client cert testing.

 i'm planing to add 2 new constants:
 
 const unsigned long LOAD_NOCOOKIES = 1  15;
 const unsigned long LOAD_NOAUTH  = 1  16;
 the second constant would be the fix for
 https://bugzilla.mozilla.org/show_bug.cgi?id=646686

I don't see a problem with adding these. But, we should be clear on what the 
final goal of this work is.

Cheers,
Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-22 Thread Gregory Szorc
On 2/22/2013 5:41 PM, Brian Smith wrote:
 bernhardr...@gmail.com wrote:
 i'm willing to fix
 https://bugzilla.mozilla.org/show_bug.cgi?id=836602

 Summary: The rest api should not send cookies and thus now uses the
 LOAD_ANONYMOUS flag. But this flag also denies (client side)
 authentication like my custom firefox sync requires.
 therefore firefox sync is broken for me since = F18.
 Which modes of authentication does the Sync team wish to support in the 
 product?

 Currently it supports and requires (I think) HTTP authentication without 
 cookies and without SSL client certificates.

 The proposal (I think) is to support SSL client certificates with HTTP 
 authentication. But, if you area already doing SSL client authentication then 
 do you really need HTTP authentication too? Should that mode of operation be, 
 instead, SSL client authentication without HTTP authentication and without 
 cookies?

 How would the Sync client decide whether to use SSL client certificates or 
 HTTP authentication? Would there be some new UI?

 I am willing to help with things (e.g. reviewing the tests) but it is up to 
 the Sync team to decide on the prioritization of the work and decide what the 
 testing requirements are. IMO, writing tests for this will be difficult as 
 there's no framework for SSL client cert testing.

We'd likely change Sync to statically use LOAD_NOCOOKIES. The important
consideration is for cookies to not automatically creep into requests
because we don't want to leak details to the Sync server from other
parts of the domain (Mozilla's Sync servers would be receiving cookies
for mozilla.com!). Sync never uses cookies, so it shouldn't be a problem
to blanket disable them.

Honestly, Sync should probably offer an API that allows modification of
outgoing HTTP requests for non-standard setups. But, that doesn't solve
the problem that there are legitimate use cases beyond Sync that want
finer control than what LOAD_ANONYMOUS currently provides.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES

2013-02-22 Thread Boris Zbarsky

On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote:

const unsigned long LOAD_NOCOOKIES = 1  15;
... just stop sending / accepting cookies at this request


115 is LOAD_FRESH_CONNECTION, no?


const unsigned long LOAD_NOAUTH  = 1  16;
... don't add authentification headers automatically


116 is LOAD_DOCUMENT_URI.

So at the very least you'll need different values for these constants.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform