RE: webappsec tests moved to GitHub
Odin, Great job. I am working on testing documentation stuff. One of the document is the Migration Process for WG's to move to Github. Since you have done the migration, do you have any experience and thoughts to share so that we can well document it and make the migration job of other WGs easier. Thank you Bin -Original Message- From: Odin Hørthe Omdal [mailto:odi...@opera.com] Sent: Wednesday, June 05, 2013 8:30 AM To: public-webapps.w3.org Cc: Michael[tm] Smith Subject: webappsec tests moved to GitHub Hey! I moved the tests some two weeks ago without telling anyone, because I squeezed it in when I had no time anyway (magic trick that). Most of them lie here as pull requests: https://github.com/w3c/web-platform-tests/pulls/Velmont We didn't really have anything approved, AFAIK. Except for the CORS tests, but I have not finished all the review comment fixing on those. I pasted them into the pull request though, so it's possible for everyone to see, and for someone to help me get it finished. It's really not that much work. So, what's left of the move? Well, closing write access to our HG repo is the only thing left. And when we've done that, I'll take a look to see if anything changed between the revision I took in and the repo at that point. -- Odin · @odinho · Opera
RE: Fetch: HTTP authentication and CORS
That is correct. Thanks Bin From: Paul Libbrecht [mailto:p...@hoplahup.net] Sent: Wednesday, May 08, 2013 1:14 PM To: HU, BIN Cc: Hallvord Reiar Michaelsen Steen; Jonas Sicking; Anne van Kesteren; WebApps WG; WebAppSec WG Subject: Re: Fetch: HTTP authentication and CORS On 7 mai 2013, at 02:23, HU, BIN wrote: Because nonce is needed to generate the appropriate digest, the 401 challenge is required. So the lesson here is: any developer that intends to use authenticated XHR should always start with an XHR that is a simple ping-like GET, then do the real things. Right? Paul
RE: Re: Fetch: HTTP authentication and CORS
If we are talking about RFC2617 HTTP Authentication, there are 2 authentication models: (1) Basic Authentication model: Under this circumstance, basically client can send the username:password pair at the first request, e.g. in the form: https://username:passw...@www.example.com/path which in turn maps to an HTTP header Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Where username:password is BASE64-encoded. Because of the vulnerability of Basic Authentication model (without encryption), https is strongly recommended. But in practice, Basic Authentication is rarely used, and it is mostly based on a challenge-response model, where the server challenges with 401 code, and a Authentication header to ask for Basic Authentication: WWW-Authenticate: Basic realm=WallyWorld (2) Digest Authentication model: Digest scheme is always based on challenge-response, and server challenges with 401 code, Authentication heade, and other important information such as nonce, e.g.: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm=testre...@host.com, qop=auth,auth-int, nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093, opaque=5ccc069c403ebaf9f0171e9517f40e41 so that client can apply the appropriate digest algorithm, such as MD5, and generate the response: Authorization: Digest username=Mufasa, realm=testre...@host.com, nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093, uri=/dir/index.html, qop=auth, nc=0001, cnonce=0a4f113b, response=6629fae49393a05397450978507c4ef1, opaque=5ccc069c403ebaf9f0171e9517f40e41 Because nonce is needed to generate the appropriate digest, the 401 challenge is required. Hope it helps Bin -Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Monday, May 06, 2013 11:13 AM To: Jonas Sicking Cc: Anne van Kesteren; WebApps WG; WebAppSec WG Subject: Re: Re: Fetch: HTTP authentication and CORS Here I don't agree anymore. If I want to retrieve a HTTP auth-protected resource with XHR from a CORS-enabled server, the natural thing to do seems to try to pass in the user name and password in the XHR open() call. If the script author supplied user/pass and the server says 401 on a request without Authorization: surely the natural next step is to re-try with Authorization:? If the caller to the XHR.open() call provided a username and password, then shouldn't the implementation send that information in the *first* request rather than waiting for a 401? I'd like to do that, but Anne thinks it violates the HTTP protocol (and apparently is hard to implement on top of certain networking libraries?). Any networking devs who would like to comment on that? -- Hallvord R. M. Steen Core tester, Opera Software
RE: [XHR] test nitpicks: MIME type / charset requirements
Since XHR is the API to facilitate a valid HTTP transaction, IMHO, it should be fully compliant with HTTP - no more and no less. A valid HTTP request and response should be interpreted consistently across UA's and devices. Interoperability is very important across UA's and devices. If the XHR, either spec or implementation, is not fully compliant with HTTP, it will give users an unpleasant experience resulting from the interoperability issue. Thanks Bin -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Monday, May 06, 2013 6:06 PM To: Julian Aubourg; Anne van Kesteren Cc: Hallvord Reiar Michaelsen Steen; public-webapps WG Subject: Re: [XHR] test nitpicks: MIME type / charset requirements On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? This is how the web is rings like an 'argument from authority'. I'm generally less concerned about those than I believe you are, but I think Julien's questions here are important. It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). (maybe.) 1. Require the same from everyone. So is there a concrete dominanant implementation that is case-sensitive? Because requiring case-insensistive matching from everyone would seem to meet your requirement above, in principle. And it might even be that with good clear specifications and good test suites that the dominant implementation reinforces a simpler path for authors. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on I know this has happened on the web for various cases. But it actually depends on having a sufficiently non-conformant implementation be sufficiently important to dominate (rather than be a known error case that is commonly monkey-patched until in a decade or so it just evaporates). I don't see any proof that it is *bound* to happen. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RE: Reminder: Please register for Face to face by Friday
Paypal was acquired by eBay, but kept Paypal brand, called eBay's Paypal business. Bin Hu | Service Standards | ATT +1-425-214-3305 From: Chris Wilson [mailto:cwi...@google.com] Sent: Wednesday, April 03, 2013 3:15 PM To: Travis Leithead Cc: Chaals Nevile; public-webapps WG Subject: Re: Reminder: Please register for Face to face by Friday Paypal is in the same building complex with eBay (the address is the same, although I think the building number is different). On Wed, Apr 3, 2013 at 3:06 PM, Travis Leithead travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote: Chaals, The wiki says the host is eBay with an address given. Is the address still accurate? If not, will someone who knows the correct address update the wiki? http://www.w3.org/wiki/Webapps/April2013Meeting -Original Message- From: Chaals Nevile [mailto:w...@chaals.commailto:w...@chaals.com] Sent: Wednesday, April 3, 2013 3:49 AM To: public-webapps WG Subject: Reminder: Please register for Face to face by Friday Hi folks, a reminder that Paypal (our meeting hosts) have asked us to have registration done by Friday to help their planning. If you expect to attend, but haven't got around to telling us, please do so at https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ If you are hoping to come but unable to confirm by Friday, please go ahead and register now, and note in the general comments section that you are not confirmed and when you expect to know for sure. If you do not register by the deadline, and later decide you want to attend, please contact Art and me, and we will see what we can do. cheers Chaals -- Chaals - standards declaimer
