On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey d...@arandomurl.com wrote:
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight? if so then none of the
caching will
Would this be allowed for both requests with credentials and requests
without credentials? The security implications of the two are very
different.
/ Jonas
On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
When the user agent is about to make its first preflight to an
On Thu, Feb 19, 2015 at 3:30 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the
I think that POSTing JSON would probably expose to CSRF a lot of things
that work over HTTP but don't expect to be interacted with by web browsers
in that manner. That's why the recent JSON encoding for forms mandates
that it be same-origin only.
On Thu Feb 19 2015 at 12:23:48 PM Jonas Sicking
I am not sure about that. Based on the premise that the browser itself
doesn't leak data, I think it is possible to make a web site safe. In
order to achieve that, we to make sure, that
a) the (script) code doesn't misbehave (=CSP);
b) the integrity of the (script) code is secured on the server
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote:
Access-Control-Allow-Origin-Wide-Cache: [origin]
This has some pretty implications for server deployments that host
mutual distrustful applications. Now, these servers are already
pretty well hosed from other directions,
On 18 February 2015 at 06:31, Brad Hill hillb...@gmail.com wrote:
Some of the things that argue against /.well-known are:
1) Added latency of fetching the resource.
It's not available everywhere yet, but you could push it, based on the below.
2) Clients hammering servers for non-existent
I am not sure about that...
Data has three states:
(1) Data in storage
(2) Data on display
(3) Data in transit
Because browsers can't authenticate servers with any degree of
certainty, they have lost the data in transit state. That leaves a
poor choice of options, like side loading on
Anne van Kesteren ann...@annevk.nl wrote:
Concerns raised by Monsur
https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html
and others before him are still valid.
When you have an HTTP API on another origin you effectively get a huge
performance penalty. Even with caching of
On Thu, Feb 19, 2015 at 11:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST
On Thu, Feb 19, 2015 at 2:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the
performance impact is significant since most of the time is used up by
latency, the CORS preflight request essentially double the time it takes to
do
Dale Harvey d...@arandomurl.com wrote:
The REST api pretty much by design means a unique url per request
CouchDB has http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API,
which allows you to fetch or edit and create multiple documents at
once, with one HTTP request. CouchDB's documentation says
On Tue, Feb 17, 2015 at 8:43 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Anne van Kesteren wrote:
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
Individual resources should not be able to declare policy for the whole
server, ...
With HSTS we gave up on
On Thu, Feb 19, 2015 at 11:43 AM, Brian Smith br...@briansmith.org wrote:
1. Preflight is only necessary for a subset of CORS requests.
Preflight is never done for GET or HEAD, and you can avoid preflight
for POST requests by making your API accept data in a format that
matches what HTML forms
Hi, I noted the bugs, this thread, and the document in the HTML accessibility wiki where I am trying to collate stuff about focus navigation and similar keyboard access issues (in what might yet be a vain attempt to really improve the situation which is overall pretty dismal still):
What is it about PouchDB and CouchDB that causes them to require
preflight for all of these requests in the first place? What is
difficult about changing them to not require preflight for all of
these requests?
The REST api pretty much by design means a unique url per request, in this
case a
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein every
request is to a different url (which is unlikely to change), the performance
impact is significant since most of the time is used up by latency,
On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey d...@arandomurl.com wrote:
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight?
To be clear, my comment was about
Will take a look at the content-type on GET requests, thanks
I believe none of these require preflight unless a mistake is being
made (probably setting Content-Type on GET requests).
http://www.w3.org/TR/cors/#preflight-result-cache-0
If the cache is against the url, and we are sending
Dale Harvey d...@arandomurl.com wrote:
I believe none of these require preflight unless a mistake is being
made (probably setting Content-Type on GET requests).
http://www.w3.org/TR/cors/#preflight-result-cache-0
If the cache is against the url, and we are sending requests to different
The cache would be on a per requesting origin basis as per the headers
above. The Origin and Access-Control-Allow-Origin would not take part
in this exchange, to make it very clear what this is about.
I dont want to conflate what could be seperate proposals, but they seem
closely related, this
so presumably it is OK to set the Content-Type to text/plain
Thats not ok, but may explain my confusion, is Content-Type considered a
Custom Header that will always trigger a preflight? if so then none of the
caching will apply, CouchDB requires sending the appropriate content-type
I tried
When the user agent is about to make its first preflight to an origin
(timeout up to the user agent), it first makes a preflight that looks
like:
OPTIONS *
Access-Control-Request-Origin-Wide-Cache: [origin]
Access-Control-Request-Method: *
Access-Control-Request-Headers: *
If the
[ - the easily recognizable p-webapps subscribers ]
On 2/18/15 12:50 PM, Dimitri Glazkov wrote:
Following Art's suggestion [1], I propose a Web Components-specific
F2F with with the primary goal of reaching consensus on the Shadow DOM
contentious bits [2].
When: Friday, April 24, 2015
On Feb 19, 2015 3:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey d...@arandomurl.com wrote:
With Couch / PouchDB we are working with an existing REST API wherein
every
request is to a different url (which is unlikely to change), the
performance
If the cache is against the url, and we are sending requests to different
urls, wont
requests to different urls always trigger a preflight?
I just realised my mistake, GETS without custom headers should need to
trigger preflight requests, sorry
On 19 February 2015 at 13:31, Dale Harvey
On 2/19/15 9:57 AM, Anders Rundgren wrote:
Where are you supposed to propose new APIs? Can such proposal be made
by non-W3C members?
This was a proposal for using Chrome Native Messaging as the
foundation for a new standard.
Perhaps you should pursue the Community Group process
Hi,
I find that understanding CORS is a really not easy.
It seems that what is missing is an general overview document,
that would start by explaining why the simplest possible method
won't work, in order to help the user understand then why more
complex method are needed.
For example the
On 19 Feb 2015, at 22:04, Martin Thomson martin.thom...@gmail.com wrote:
On 18 February 2015 at 06:31, Brad Hill hillb...@gmail.com wrote:
Some of the things that argue against /.well-known are:
1) Added latency of fetching the resource.
It's not available everywhere yet, but you could
On Thu, Feb 19, 2015 at 10:05 PM, Jeffrey Walton noloa...@gmail.com wrote:
For what its worth, I'm just the messenger. There are entire
organizations with Standard Operating Procedures (SOPs) built around
the stuff I'm talking about. I'm telling you what they do based on my
experiences.
From
On 02/18/2015 08:59 AM, David Leon Gil wrote:
W.r.t. WebCrypto-Next:
It would be wonderful to see a few useful algorithms added to the spec:
- a modern VOF (e.g., SHAKE256)
- a fast hash function (e.g., BLAKE2b)
- a sequential-hard KDF (e.g., scrypt)
- some non-NSA curves
New
* Jonas Sicking wrote:
We most likely can consider the content-type header as *not* custom.
I was one of the people way back when that pointed out that there's a
theoretical chance that allowing arbitrary content-type headers could
cause security issues. But it seems highly theoretical.
I suspect
On 2/19/15 4:28 PM, henry.st...@bblfish.net wrote:
Hi,
I find that understanding CORS is a really not easy.
It seems that what is missing is an general overview document,
that would start by explaining why the simplest possible method
won't work, in order to help the user understand then why
On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
When the user agent is about to make its first preflight to an origin
(timeout up to the user agent), it first makes a preflight that looks
like:
OPTIONS *
Access-Control-Request-Origin-Wide-Cache: [origin]
* Martin Thomson wrote:
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote:
Access-Control-Allow-Origin-Wide-Cache: [origin]
This has some pretty implications for server deployments that host
mutual distrustful applications. Now, these servers are already
pretty well hosed
On Thu, Feb 19, 2015 at 5:28 AM, Arthur Barstow art.bars...@gmail.com
wrote:
When will you be able to confirm the location? Regardless, I think we
should consider the meeting as confirmed.
Working on it now. Will report back shortly.
:DG
On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton noloa...@gmail.com wrote:
For the first point, Pinning with Overrides
(tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect
example of the wrong security
On Thu, Feb 19, 2015 at 6:10 PM, Jeffrey Walton noloa...@gmail.com wrote:
On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
What would you suggest instead?
Sorry to dig up an old thread.
Here's yet another failure that Public Key Pinning should have
stopped, but the
On Thu, Feb 19, 2015 at 12:15 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 6:10 PM, Jeffrey Walton noloa...@gmail.com wrote:
On Mon, Feb 16, 2015 at 3:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
What would you suggest instead?
Sorry to dig up an old thread.
HTTPS Client Certificate Authentication is supported by all browsers since
almost 20 years back.
It exposes a fully standardized interface to Web Applications which simply is
an URL.
In spite of that it is entirely proprietary with respect to integration in the
browser platform
with
On 2015-02-19 15:47, Arthur Barstow wrote:
On 2/19/15 9:35 AM, Anders Rundgren wrote:
Hi Anders,
Hi Art,
In the spirit of restricting postings on this list to the group's
chartered scope ...
http://www.w3.org/2008/webapps/
This work will include both documenting existing APIs such as
On 2/19/15 9:35 AM, Anders Rundgren wrote:
Hi Anders,
In the spirit of restricting postings on this list to the group's
chartered scope ...
I don't see a clear and direct connection between your posting [1] and
WebApps' chartered scope [2]. If I missed such a connection, please
focus your
On Thu, Feb 19, 2015 at 12:38 PM, Brad Hill hillb...@gmail.com wrote:
I think that POSTing JSON would probably expose to CSRF a lot of things that
work over HTTP but don't expect to be interacted with by web browsers in
that manner. That's why the recent JSON encoding for forms mandates that
On Thu, Feb 19, 2015 at 4:31 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 19, 2015 at 10:05 PM, Jeffrey Walton noloa...@gmail.com wrote:
For what its worth, I'm just the messenger. There are entire
organizations with Standard Operating Procedures (SOPs) built around
the stuff I'm
* Martin Thomson wrote:
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
I missed that. In which case I'd point out that `OPTIONS *` is very
poorly supported. Some people (myself included) want it to
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote:
The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`.
I missed that. In which case I'd point out that `OPTIONS *` is very
poorly supported. Some people (myself included) want it to die a
flaming death.
47 matches
Mail list logo
