Jonas Sicking wrote:
I would tentatively say the following are not valid reasons to
restrict a header:
4) It could result in content that the UA might not be able to parse
as text or as XML (this can happen anyway with no custom headers).
If a header will always cause the UA to not be
Jonas Sicking wrote:
Julian Reschke wrote:
Jonas Sicking wrote:
I would tentatively say the following are not valid reasons to
restrict a header:
4) It could result in content that the UA might not be able to parse
as text or as XML (this can happen anyway with no custom headers
Hi,
while discussing RFC2518bis, the IETF WebDAV WG got feedback ([1])
pointing out a potential attack scenario that hasn't been discussed
before a lot, and mainly depends on three factors:
- HTTP methods such as PUT or DELETE that may overwrite/delete existing
content
- collaborative
Boris Zbarsky wrote:
Jonas Sicking wrote:
One argument is that it's simply impossible to work around an XHR
implementation that changes the casing in a way that the server
doesn't expect. For example if the server wants a 'doit' method and
the XHR implementation case folds to uppercase, the
Anne van Kesteren wrote:
On Thu, 20 Apr 2006 23:38:56 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
In the end, we want to have these clients/libraries fixed, right?
I guess that's the question. Is it sensible to implement it as
case-sensitive knowing that you probably break content
Mark Nottingham wrote:
[ from the big comment e-mail; raising as a separate issue, as requested ]
The current draft says that:
If the method is POST or PUT, then the data passed to the send() method
must be used for the entity body.
This doesn't account for other request methods that may
Mark Nottingham wrote:
RFC2616, section 4.3;
A message-body MUST NOT be included in a request if the specification
of the request method (section 5.1.1) does not allow sending an
entity-body in requests.
GET, HEAD and DELETE do not allow for an entity-body in requests.
Granted, it's not
Gorm Haug Eriksen wrote:
...
Please consider that if arbitrary methods can not be used with XHR,
future specification may be forced to use POST instead. So by banning
methods you don't know, you will make it more likely that people use
POST in the future, which is the contrary of what you
Mark Baker schrieb:
On 5/22/06, Mark Baker [EMAIL PROTECTED] wrote:
I think that was ACTION-145 on Gorm.
Doh, I meant to paste this;
http://www.w3.org/2006/webapi/track/actions/145
Hi,
first of all, I checked current implementations, using the verbs GET
(RFC2616), PROPFIND (RFC2518),
Ian Hickson schrieb:
On Wed, 7 Jun 2006, Mark Nottingham wrote:
Blindly standardising what one vendor does doesn't make sense; do you
know *why* they consider it a security feature?
The reputed security problems with various HTTP methods have been
brought up many times, but I have yet to
Charles McCathieNevile schrieb:
POST could be used to do so, but there is nothing in its defined
semantics that forces it to be used like that. POST hands the body to
something and says do with this as you see fit, PUT says begone, this
is your replacement.
Well. A server may replace a
Bjoern Hoehrmann schrieb:
* Julian Reschke wrote:
[...]
Could you propose specific text to be included in the specification with
respect to support for HTTP methods? It is not clear to me why we are
still discussing this, so having clear proposals for text would help a
lot.
Fair enough
Boris Zbarsky schrieb:
Charles McCathieNevile wrote:
... it exposes users to a potential security risk, and there's
nothing the user can do about it except disabling scripting. I think
that is a problem.
SURE. That doesn't make it a bug per se. It also exposes the user to a
bunch of
Gorm Haug Eriksen schrieb:
On Fri, 09 Jun 2006 10:56:20 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
So please leave this to those who actually control HTTP + extensions,
which is the IETF.
IETF should make an RFC much like http://www.ietf.org/rfc/rfc4229.txt
describing the http methods
Subbu Allamaraju schrieb:
c. Per the current draft, getResponseHeader() is required to return an
empty string if a given header is not present. From programming API
point of view, a value of null is more natural.
...
In particular, HTTP allows headers to be present with no value, and that
Ian Hickson schrieb:
On Wed, 2 Aug 2006, Julian Reschke wrote:
If compatibility to existing code (which doesn't check for null) is the
driver here, then please consider adding a new method such as
isHeaderPresent(headername).
Purely out of interest, could you give the use case?
Only
Hi,
thanks for adding the methods from RFC2518/RFC3253/RFC3648/RFC3744.
However, I'm missing MKREDIRECTREF and UPDATEREDIRECTREF as defined in
RFC4437. Could these be added as well?
Best regards, Julian
Anne van Kesteren schrieb:
On Tue, 10 Oct 2006 00:52:50 +0200, Subbu Allamaraju
[EMAIL PROTECTED] wrote:
I find a bit odd for the XMLHttpRequest draft to require all
implementations to support the listed method names. In particular,
what the motivation for the conformance statement -
[...]
Subbu Allamaraju schrieb:
Few points -
(a) I don't think the question is whether it is hard to implement a
certain method or not. It certainly is possible to implement. I'm trying
to find the rationale.
(b) IMO, XHR spec is concerned about specifying the semantics of what
happens when a
Subbu Allamaraju schrieb:
On 10/11/06, *Julian Reschke* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Subbu Allamaraju schrieb:
Few points -
(a) I don't think the question is whether it is hard to implement a
certain method or not. It certainly is possible
Ari Krupnik schrieb:
The archives of this list have a lot of information on current state
of the art, but much of it is scattered. Is there a page that
summarizes the implemented features in different UAs somewhere? In
particular (here's the bit relevant to this thread) I'm looking for a
list
Mark Baker schrieb:
If you can't guarantee that at least a core set of methods will work,
the API is simply useless.
I disagree.
Common practice with HTTP is what declares what methods are in use at
any given time. As an API to HTTP - which provides portability, not
interoperability - XHR
Anne van Kesteren schrieb:
On Tue, 13 Feb 2007 16:59:12 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
I think the spec needs to be carefully checked for usage of
RFC2119/BCP14 terminology. For instance
(http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type
Maciej Stachowiak schrieb:
Yes. The problem is the spec saying ...nothing SHOULD be done I
think it's better to be explicit what the implementation should do (in
this case, ignore the method call).
I agree that using active voice is better than using passive voice, but
there are no
Anne van Kesteren schrieb:
On Tue, 13 Feb 2007 17:11:03 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
Yes. The problem is the spec saying ...nothing SHOULD be done I
think it's better to be explicit what the implementation should do (in
this case, ignore the method call).
Oh, ok
Hi,
see below some comments on the current draft.
Best regards, Julian
+++
1. Introduction
First, the object is data transport agnostic - it supports any data
format, including XML.
Actually, it doesn't. As far as I can tell, it only supports text based
formats and XML. There's no way
Anne van Kesteren schrieb:
Actually, it doesn't. As far as I can tell, it only supports text
based formats and XML. There's no way to send or retrieve binary content.
Fair enough. In due course it will though. Fixed.
That would be great. It's a missing piece for writing a useful WebDAV
Julian Reschke schrieb:
User agents MUST at least support the following list of methods (see
[RFC2616]):
* GET
* POST
* HEAD
* PUT
* DELETE
Why is OPTIONS missing from this list?
Because it's not generally supported and vendors had concerns about
it. If you can
Anne van Kesteren schrieb:
On Sat, 17 Feb 2007 22:08:58 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
OK, I just tested with IE7 and Firefox2, which support it. I know that
IE6 (with the ActiveX object) supports it as well. Opera 9 doesn't,
and it seems to me that you're in a better
Anne van Kesteren schrieb:
On Sat, 17 Feb 2007 21:48:38 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
Section 4.2 already talks about this quite explicitly. What do you
want it to say?
First of all, it's only the last paragraph of 4.2 which talks about
this, so being a bit more specific
Anne van Kesteren schrieb:
On Sun, 18 Feb 2007 11:34:01 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
So what do we do with the other headers which are documented to be
non-repeatable, but do not appear in that list?
Dunno, it would've been nice if
http://www.iana.org/assignments/message
Anne van Kesteren schrieb:
On Sun, 18 Feb 2007 11:46:49 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
Well, I'm asking because this spec is supposed to document existing
practice, right? Do we have reliable data about what the applications
really do here?
It does not document existing
Sunava Dutta schrieb:
This is fantastic, we took a look at the working draft and it looks great.
The IE team's looking forward to seeing it published!
Good to hear.
Are you actually planning to implement it? Such as support for WebDAV
method names? (remember that's a SHOULD-level
William J. Edney schrieb:
Hi Sunava -
It should be made clear that these methods work *only* with IE's
'ActiveX' http object. The new built-in IE7 'native XMLHttpRequest'
That's why I raised a bug report calling that a regression
Anne van Kesteren schrieb:
For XML parsing, DOM3 Load (or another dedicated API) could provide
much more control. Obviously, we cannot remove responseXML from
XMLHttpRequest, but not adding more known formats sounds like a good
idea to me.
Is such control really needed? For most people
Hi all,
See below my updated set of comments (some of the previously mentioned
problems have been fixed, thanks for that).
Best regards, Julian
-- snip --
Review of http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070227/.
1.2 Conformance
conforming implementation
A user agent must
Bjoern Hoehrmann schrieb:
* Julian Reschke wrote:
The syntax for the user or password arguments depends on the scheme
being used. If the syntax for either is incorrect per the production
given in the relevant scheme user agents must throw a SYNTAX_ERR
exception. The user and password must
Anne van Kesteren wrote:
Based on feedback from Microsoft the algorithm used by responseText now
takes the potential BOM of the entity body into account. Please let me
know if you spot any issues with this:
Carsten Orthbandt wrote:
Julian Reschke schrieb:
You're violating a SHOULD level requirement of HTTP/1.1 then. Sorry, but
that's what you get for that :-).
- I definately dont want to see future browsers choke on that
Actually, I'm tempted to say it would be good for the web if more UAs
Carsten Orthbandt wrote:
...
My wording here was probably unclear. My intent is not to have the spec
define how or when an UA should report errors. I'd like the spec to define
what is an actual error in the processing and what are merely different
execution paths of the algorithms laid out.
Jim Ley wrote:
Julian Reschke [EMAIL PROTECTED]
I have to agree here. If a recipient decides to do content-type
guessing, the fact that the type is not what was tested is not an
error. One more reason not to guess in the first place.
But it might be what's tested just invalid - if the user
Carsten Orthbandt wrote:
I don't want to let loose a big discussion about best practices
here. The issue at hand is certainly solvable on our side.
But I do see a problem here with changing the spec in a way that
obviously breaks old apps that were fully standards compliant.
There is no
Bjoern Hoehrmann wrote:
* Carsten Orthbandt wrote:
Bjoern Hoehrmann schrieb:
Why don't you use less , , and ]] sequences in the content and wrap
it into x.../x?
If my response body is (literal example)
---snip---
ut:7325
ubc:0
---snap---
there's obviously some hesitation to wrap that as
Jonas Sicking wrote:
The XHR spec currently allows users to set the Proxy-Connection header
using setRequestHeader method. I couldn't find a spec for it other than
some discussions here:
...
As far as I can tell, the spec doesn't even mention the header.
Are you saying the spec should
Jonas Sicking wrote:
...
Yes, if it's a security problem not to. IMHO that should be the
determining factor.
Actually, I'm wondering if we should disallow any header starting with
Proxy-. For example Proxy-Authorization header looks scary to me.
...
Well, this is yet another case where
Martin Kail wrote:
I'm sure 1000 people have said this before me, but here it is again to
show we really want this feature.
I think the XMLHttpRequest object should handle all status codes during
a GET, POST or PUT requests. More specifically, redirects codes (30x)
should be set and the
Maciej Stachowiak wrote:
This is a known issue, see
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19.
It seems that pending resolution of this issue, it's inappropriate to
require XMLHttpRequest implementations to sometimes send requests that
may be in violation of the RFC.
Maciej Stachowiak wrote:
We're now talking about caching, and I totally agree that more
clarifications are required here (I was referring to the actual
message transmission in my reply).
Caching most certainly affects the message transmission behavior of a
caching client library
Jonas Sicking wrote:
Actually, once we're supporting cross site GET requests, I think we
there should definitely mention that the entity body of GET (and
probably HEAD) requests are dropped. Otherwise there is some risk that
there are servers out there that will do dangerous things when
Jonas Sicking wrote:
No. Look, if you don't want to have to take on the extra work of
fully supporting HTTP (for what is, admittedly, currently a fringe
case), fine, don't. Just please don't ask that we tell those who are
willing to do so, that they can't.
Given that none of the current
Anne van Kesteren wrote:
On Sat, 09 Feb 2008 12:57:18 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
...looking at
http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/006.htm...
It seems there are no test cases that check that a user agent either
correctly handles unknown method names
Alexey Proskuryakov wrote:
I do not see how it is something the XHR spec can change - it's
obviously an RFC 2616 domain, and RFC 2616 is very explicit in what it
says about header name case insensitivity.
+1.
...
BR, Julian
Laurens Holst wrote:
I don’t really see how POST is less harmful than DELETE. POST (if used
in a REST-y way) can be used to wreak serious havoc (e.g. spam messages,
overload server data capacity, post viruses, adding new super user
accounts for the hacker, change settings such as passwords,
Peter Michaux wrote:
The XMLHttpRequest spec says The setRequestHeader() method appends a
value if the HTTP header given as argument is already part of the list
of request headers.
This is fine but what is a problem is whether or not a new
XHMHttpRequest object has any default headers. I was
Sunava Dutta wrote:
IMHO we need either removeRequestHeader(), getRequestHeader(), or both.
GetRequestHeader could pose a security risk, because you could then
GetRequestHeader (Cookie) and steal HTTPOnly cookies.
Sure. It would need to be done correctly. That doesn't change the fact
that
Anne van Kesteren wrote:
On Thu, 17 Apr 2008 15:31:37 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
The whole append semantics is problematic as long as the user can't
find out what the current value is.
IMHO we need either removeRequestHeader(), getRequestHeader(), or both.
Yes, you have
Anne van Kesteren wrote:
On Mon, 12 May 2008 17:24:16 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Well, we just heard from people complaining about XHR implementations
pre-filling request headers, and thus causing clients to create broken
content-type headers (because of the append
Anne van Kesteren wrote:
On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
- On the send algorithm, step 4 (If stored method is GET act as if
the data argument is null), why only GET and not HEAD, also?
In order to subset HTTP as little
Anne van Kesteren wrote:
I see. (Your original message seemed to imply the list was not correct.)
To be honest, and as I've stated in my reply to Julian, I'm not sure
what the rationale is for some of them. Hopefully implementors can chime
in on this thread and provide feedback for why each
Ian Hickson wrote:
...
Incidentally, I think I would recommend removing the blacklist from AC,
since AC has a whitelist. Having both seems pointless.
...
You mean disallowing all headers except a known list??? Nope.
Again, that would mean profiling HTTP, and make it impossible to deploy
Ian Hickson wrote:
On Wed, 14 May 2008, Julian Reschke wrote:
The problem is that concepts such origin and determining the
encoding of a text/html stream are not defined anywhere else. It's not
really clear to me what to do about that.
In some cases, it may be possible to copy the current
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5 is getting progressively closer
to defining it. XHR1 doesn't
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin (for instance) is pretty well
understood by browser vendors, and HTML5
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
Ian Hickson wrote:
On Thu, 15 May 2008, Julian Reschke wrote:
The spec can't be more ready than all normative references.
Sure it can. The concept of origin
Ian Hickson wrote:
...
What's wrong with referencing HTML5? Why can't the spec be more ready than
its normative references? We're only really referencing the concept, the
details aren't particularly critical to XHR.
...
Because, by definition, normative references are part of the
Laurens Holst wrote:
Julian Reschke schreef:
Sorry, was reading one thing, but thinking about something else.
Thinking of it, could you please add a clarification that setting to
an empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX
Laurens Holst wrote:
Julian Reschke schreef:
Sorry, was reading one thing, but thinking about something else.
Thinking of it, could you please add a clarification that setting to
an empty string is legal, and MUST NOT be ignored? I recall that
Microsoft's original XHR (ActiveX
Ian Hickson wrote:
...in which case I'd say that (a) the references aren't normative after
all, and (b) the spec itself can't be normative as it is written.
I don't mind calling the references informative if that's what it takes.
I'm not sure what practical difference it would make.
You
Anne van Kesteren wrote:
On Tue, 13 May 2008 09:25:42 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
On Mon, 12 May 2008 17:26:07 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
- On the send algorithm, step 4 (If stored method is GET act
Anne van Kesteren wrote:
There have been a lot of messages about referencing HTML5 and how we can
mitigate that. I don't think that copying the text from HTML5 is an
option. The Window specification is fairly complex and especially the
interaction with browsing contexts is a complex bit of
Anne van Kesteren wrote:
On Thu, 15 May 2008 20:56:42 +0200, Laurens Holst
[EMAIL PROTECTED] wrote:
Why was this changed? Why should user agents pretend that they know what
kind of resource the user expects by setting an Accept header that is
unreliable? FWIW, Internet Explorer and Safari
Anne van Kesteren wrote:
Since this is the second Last Call and credentials are already following
each other (and the same for other similar steps) I've decided not to
change this.
Unfortunately.
c) Structure: It would be nice if Section 4 had more structure.
Rightnow it's ugly to navigate
Boris Zbarsky wrote:
Julian Reschke wrote:
Yes, I noticed that. For instance, it happens for application/..+xml,
where it's really useless. Shouldn't this be restricted to text/*?
That could perhaps be done. The initial implementation just does it no
matter the MIME type so as to avoid
Jonas Sicking wrote:
...
If */* is semantically the same as not sending the header at all, and
the former works with more servers, I would prefer that we use the former.
...
I would prefer not to silently change what the client requested.
If a server can't cope with it (evidence, please!),
Anne van Kesteren wrote:
On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
But what IMHO happens all over again is that strange choices in the
design are defended with the statement this is what the vendors do,
or want to do, and when we check it, that turns out
Julian Reschke wrote:
...
Data loss is not a safe choice, it's a bad choice.
Do you have any evidence of deployed code that would break if this would
throw?
...
I just tried with FF3 and IE7.
Using a non-ns-wellformed document:
- FF3: happily sends it
- IE7: couldn't figure out how
Julian Reschke wrote:
Boris Zbarsky wrote:
Julian Reschke wrote:
Using a non-ns-wellformed document:
- FF3: happily sends it
Out of curiosity, what did this document look like? What got sent?
I removed the document element and added a comment node, so it looked like:
!-- foo
Boris Zbarsky wrote:
Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the
server side, I'm not sure it makes sense to bail on attempts to
serialize such documents. In particular, if the document _is_ parsed
with a non-namespace-aware XML parser
Bjoern Hoehrmann wrote:
* Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in
Which you can, with a non-NS-aware XML parser.
My point was that the XHR draft currently requires using a
Stewart Brodie wrote:
If a server can't cope with it (evidence, please!), fix it.
Some older versions of Microsoft IIS are the servers that I've come across
that fail to cope with it. It is unrealistic to expect these to be
undeployed any time soon. The comment in my code does not specify
Julian Reschke wrote:
...
Currently there is no conversion, and what is specified clearly can
cause implementations to create broken requests, where the code worked
before.
...
...even without looking for it, I came across this one:
https://jersey.dev.java.net/servlets/ReadMsg?list
Anne van Kesteren wrote:
When invoking request.setRequestHeader('Accept', null):
- Firefox 3b5 removes the Accept header
- Internet Explorer 8 (in IE7 mode) sends Accept: null
- Safari 3.1.1 sends Accept: null
- Opera 9.24 sends Accept: text/html, application/xml;q=0.9,
application/xhtml+xml,
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari are
conformant here. (null and undefined are simply stringified.)
Not terrible useful, I would say
Anne van Kesteren wrote:
Or are you claiming that people who set a header to null *really* want
the specified behaviour?
It's consistent with other JavaScript APIs were null also means null.
Overloading this API to also do removal of the header is not a goal here
and is simply a bug in
Maciej Stachowiak wrote:
Treating null as empty string here may be sensible (no strong opinion
either way) but removing the header when set to empty seems wrong. If
header removal is really essential we should add a method for it.
In HTTP, absence of a header is different from having an
Bjoern Hoehrmann wrote:
* Julian Reschke wrote:
- If the URL parameter can be a IRI, then somewhere later on we need to
state that it needs to be transformed to a URI before it's put on the wire.
Actually that is for the HTTP specification to define, which right now
does so implicitly
Jonas Sicking wrote:
These should absolutely not be under control of web content.
The Referer header is used by some web servers for security checks so
allowing this to be settable would work around that. Servers can't
currently rely on the header being there due to some firewalls/proxies
Anne van Kesteren wrote:
...
We shouldn't let what webidl says dictate what we do one way or the
other. It's just a spec for the idl language, not a recommendation for
how interfaces should behave.
null/undefined are not really part of the setRequestHeader() method. We
just need to deal
Julian Reschke wrote:
...
If stored method is GET act as if the data argument is null.
Another case of HTTP/1.1 being profiled. Don't do it.
...
For the record, the HTTPbis WG discussed the issue of GET/HEAD with
request bodies a few months ago, and the resolution was that in general
Anne van Kesteren wrote:
- If the URL parameter can be a IRI, then somewhere later on we need
to state that it needs to be transformed to a URI before it's put on
the wire.
Added a transformation step as per 3.1 and also required throwing a
SYNTAX_ERR in case of failure (ToASCII operation
Julian Reschke wrote:
That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have
any kind of interoperability here.
...so this should probably be covered by the test suite...
BR, Julian
Anne van Kesteren wrote:
On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
Julian Reschke wrote:
That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't
have any kind
Anne van Kesteren wrote:
I was mentioning it because MS apparently *does* run the test suite,
so adding a test would help ensure the problem appears on their radar.
I failed adding a non-ASCII file name through subversion to
tc.labs.opera.com so I guess that has to wait until we move the
93 matches
Mail list logo
