Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
hi i tried to create the patch for 846629 but ran into troubles. (from JS the constants are all 0) i have attached a (incomplete) patch at bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=846629 Maybe someone can point me to missing part between c++ <-> JS constant s handling? Am Freitag, 1. März 2013 06:41:41 UTC+1 schrieb 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
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
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
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
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 > > > > > > (1<<25) 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
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 > > (1<<25) 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
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 (1<<25) 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
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=719791&action=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 > > > > 1<<15 is LOAD_FRESH_CONNECTION, no? > > > > > const unsigned long LOAD_NOAUTH = 1 << 16; > > > ... don't add authentification headers automatically > > > > 1<<16 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
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 1<<15 is LOAD_FRESH_CONNECTION, no? const unsigned long LOAD_NOAUTH = 1 << 16; ... don't add authentification headers automatically 1<<16 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
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
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
LOAD_ANONYMOUS + LOAD_NOCOOKIES
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