|
Can anyone help?
I am looking for excellent Python scripts to upload large data files over the internet.
Regards.
David
|
_______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
_______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
|
Dear All,
I am looking for a nitty-gritty Python Ajax script to fire off a number of processing programmes, periodically checking their operations, sending messages back to an HTML div form by sending back the links of generated data files, to be downloaded by end users.
I am using .NET IIS 6.0 and Windows Server.
Regards.
David
|
_______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
|
Hello, there.
Has anyone tried calling zip.py in feedback.py and print out an innerHTML to provide a download link?
I find difficult to make it work.
Sincerely,
David
|
_______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
It would be lovely if we could allow WSGI applications to reliably accept Unicode paths. That is to say, allow WSGI apps to have beautiful URLs like Wikipedia's, without requiring URL-rewriting magic. (Which is so highly server-specific, potentially unavailable to non-admin webmasters, and makes WSGI app deployment more difficult than it already is.) If we could reliably read the bytes the browser sends to us in the GET request that would be great, we could just decode those and be done with it. Unfortunately, that's not reliable, because: 1. thanks to an old wart in the CGI specification, %XX hex escapes are decoded before the character is put into the PATH_INFO environment variable; 2. the environment variables may be stored as Unicode. (1) on its own gives us the problem of not being able to distinguish a path-separator slash from an encoded %2F; a long-known problem but not one that greatly affects most people. But combined with (2) that means some other component must choose how to decode the bytes into Unicode characters. No standard currently specifies what encoding to use, it is not typically configuarable, and it's certainly not within reach of the WSGI application. My assumption is that most applications will want to end up with UTF-8-encoded URLs; other choices are certainly possible but as we move towards IRI they become less likely. This situation previously affected only Windows users, because NT environment variables are native Unicode. However, Python 3.0 specifies all environment variable access is through a Unicode wrapper, and gives no way to control how that automatic decoding is done, leaving everyone in the same boat. WSGI Amendments_1.0 includes a suggestion for Python 3.0 that environ should be "decoded from the headers using HTTP standard encodings (i.e. latin-1 + RFC 2047)", but unfortunately this doesn't quite work: 1. for many existing environments the decoding-from-headers charset is out of reach of the WSGI server/layer and may well not be ISO-8859-1. Even wsgiref doesn't currently use 8859-1 (see below). 2. RFC2047 is not applicable to HTTP headers, which are not really 822-family headers even though they look just like them. The sub-headers in eg. a multipart/form-data chunk *are* (probably) proper 822 headers so RFC2047 could apply, but those headers are already dealt with by the application or framework, not WSGI. HTTP 1.1 (RFC2616) does refer to RFC2047 as an encoding mechanism for TEXT and quoted-string, but this makes no sense as 2047 itself requires embedding in atom-based parsing sequences which those productions are not (quoted-strings are explicitly disallowed by 2047 itself). In any case no existing browser attempts to support RFC2047 encoding rules for any possible interpretation of what 2616 might mean. Something like Luís Bruno's ORIGINAL_PATH_INFO proposal (http://mail.python.org/pipermail/web-sig/2008-January/003124.html) would be worth looking at for this IMO. It may be of questionable usefulness if the only character affected is the slash, but it also happens to solve the Unicode problem. Obviously whatever it was called it would have to be an optional additional value in the WSGI environ, as pure CGI servers wouldn't be able to supply it. Conceivably it might also be possible to have a standardised mod_rewrite rule to make the variable also available to Apache CGI scripts, but still this is far from global availability. In the meantime I've been looking at how various combinations of servers deal with this issue, and in what circumstances an application or middleware can safely recover all possible Unicode input. 'Apache' refers to the (AFAICT-identical) behaviour of both mod_cgi and mod_wsgi; 'IIS' refers to IIS with CGI. *** Apache/Posix/Python2 OK. No problem here, it's byte-based all the way through. *** Apache/Posix/Python3: Dependent on the default encoding. Apache puts bytes into the envvars but Python takes them out as unicode. If the system default encoding happens to be the same as the encoding the WSGI application wanted we will be OK. Normally the app will want UTF-8; many Linux distributions do use UTF-8 as the default system encoding but there are plenty of distros (eg. Debian) and other Unixen that do not. In any case we are getting a nasty system dependency at deploy time that many webmasters will not be able to resolve. It is sometimes possible to recover mangled characters despite the wrong decoding having been applied. For example if the system encoding was ISO-8859-1 or another encoding that maps every byte to a unique Unicode character, we can encode the Unicode string back to its original bytes, and thence apply the decoding we actually wanted! If, on the other hand, it's something like ISO-8859-4, where not all high bytes are mapped at all, we'll be losing random characters... not good. *** Apache/NT/Python2 Always unrecoverable data loss. Apache on Windows always uses ISO-8859-1 to decode the request path and put it in the Unicode envvars. This is OK so far, we have Unicode characters with the same codepoints as the original bytes. However, Python2 needs to make the envvars available as bytes. It uses the system default encoding; if that were ISO-8859-1, we'd be OK. But it never is. Western European on NT is actually cp1252, whose characters in the range 0x80 to 0x9F differ from ISO-8859-1. And if the app wants UTF-8, chances are those characters are going to come up a lot. There is as far as I know no user-selectable Windows codepage that can map all the Unicode characters up to U+00FF. *** Apache/NT/Python3 Wrong, but always recoverable. Python retreives the bytes-encoded-into-Unicode-codepoints string directly from the envvars. If the encoding should have been UTF-8 or something else other than ISO-8859-1, we can recover the original bytes by re-encoding to 8859-1, then decoding using the real charset. *** IIS/NT/Python2 Mostly unrecoverable data loss. IIS decodes submitted bytes to Unicode using UTF-8 when it can. But if there is an invalid UTF-8 sequence in the bytes it will try again using the system codepage. Python will then re-encode the Unicode envvar using the system codepage. If the app is expecting UTF-8 we can decode what Python gives us using the system codepage (ie. 'mbcs') and get back any of the submitted characters that happened to be in this server's system codepage. Other characters may be replaced by question marks or Windows's best attempts to give us something useful, which at best may be a character shorn of diacriticals and at worst something just completely wrong. NT's system codepage is never UTF-8, it is not a user-selectable option never mind the default. We can improve our chances of getting more characters through by using a character set with a wide repertoire, such as cp932 (Shift-JIS). But it's still not really proper Unicode support. If the app is expecting something non-UTF-8 there's not much hope. Even if it wanted the same character set as the system codepage, it can't be sure that the submitted bytes didn't happen to also be a valid UTF-8 sequence, and thus get mangled by IIS decoding them that way. *** IIS/NT/Python3 OK, as long as the app wants UTF-8. Incoming UTF-8 bytes are reliably converted to Unicode strings by IIS, and directly read by Python from the envvars. If the application didn't want UTF-8 the situation is about as hopeless as with Python2. *** wsgiref.simple_server/(any)/Python2 OK. Bytes all the way through. *** wsgiref.simple_server/(any)/Python3: Probably will be OK, as long as the app wants UTF-8. simple_server is currently broken in rc2. However judging by the code, it is using urllib.parse.unquote, which assumes UTF-8, so it'll be fine for apps that want UTF-8 and hopeless for those that don't. I'd be very interested to hear what other servers are doing in this situation - nginx? cherrypy's one? - and wonder if any particular behaviour should be 'blessed'. -- -- And Clover mailto:and <at> doxdesk.com http://www.doxdesk.com/ _______________________________________________ Web-SIG mailing list Web-SIG <at> python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Andrew Clover wrote:
> If we could reliably read the bytes the browser sends to us in the GET
> request that would be great, we could just decode those and be done with
> it. Unfortunately, that's not reliable, because:
>
> 1. thanks to an old wart in the CGI specification, %XX hex escapes are
> decoded before the character is put into the PATH_INFO environment
> variable;
I don't see a problem with this? At least not a problem with respect to
encoding. As it is (in Python 2), you should do something like
environ['PATH_INFO'].decode('utf8') and it should work. It doesn't seem
like there's any distinction between %-encoded characters and plain
characters in this situation.
> 2. the environment variables may be stored as Unicode.
>
> (1) on its own gives us the problem of not being able to distinguish a
> path-separator slash from an encoded %2F; a long-known problem but not
> one that greatly affects most people.
>
> But combined with (2) that means some other component must choose how to
> decode the bytes into Unicode characters. No standard currently
> specifies what encoding to use, it is not typically configuarable, and
> it's certainly not within reach of the WSGI application. My assumption
> is that most applications will want to end up with UTF-8-encoded URLs;
> other choices are certainly possible but as we move towards IRI they
> become less likely.
>
>
> This situation previously affected only Windows users, because NT
> environment variables are native Unicode. However, Python 3.0 specifies
> all environment variable access is through a Unicode wrapper, and gives
> no way to control how that automatic decoding is done, leaving everyone
> in the same boat.
>
> WSGI Amendments_1.0 includes a suggestion for Python 3.0 that environ
> should be "decoded from the headers using HTTP standard encodings (i.e.
> latin-1 + RFC 2047)", but unfortunately this doesn't quite work:
My understanding of this suggestion is that latin-1 is a way of
representing bytes as unicode. In other words, the values will be
unicode, but that will simply be a lie. So if you know you have UTF8
paths, you'd do:
path_info = environ['PATH_INFO'].encode('latin-1').decode('utf8')
As far as I can tell this is simply to avoid having bytes in the
environment, even though bytes are an accurate representation and
unicode is not.
A lot of what you write about has to do with CGI, which is the only
place WSGI interacts with os.environ. CGI is really an aspect of the
CGI to WSGI adapter (like wsgiref.handlers.CGIHandler), and not the WSGI
spec itself.
Personally I'm more inclined to set up a policy on the WSGI server
itself with respect to the encoding, and then use real unicode
characters. Unfortunately that's not as flexible as bytes, as it
doesn't make it very easy to sniff out the encoding in
application-specific ways, or support different encodings in different
parts of the server (which would be useful if, for instance, you were to
proxy applications with unknown encodings). So... maybe that's not the
most feasible option. But if it's not, then I'd rather stick with bytes.
--
--
Ian Bicking : ianb@... : http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
FWIW, there was a past discussion on these issues on mod_wsgi list. I can't really remember what the outcome of the discussion was. The discussion is at: http://groups.google.com/group/modwsgi/browse_frm/thread/2471a1a71620629f Graham 2008/11/13 Andrew Clover <and-py@...>: > It would be lovely if we could allow WSGI applications to reliably accept > Unicode paths. > > That is to say, allow WSGI apps to have beautiful URLs like Wikipedia's, > without requiring URL-rewriting magic. (Which is so highly server-specific, > potentially unavailable to non-admin webmasters, and makes WSGI app > deployment more difficult than it already is.) > > > If we could reliably read the bytes the browser sends to us in the GET > request that would be great, we could just decode those and be done with it. > Unfortunately, that's not reliable, because: > > 1. thanks to an old wart in the CGI specification, %XX hex escapes are > decoded before the character is put into the PATH_INFO environment variable; > > 2. the environment variables may be stored as Unicode. > > (1) on its own gives us the problem of not being able to distinguish a > path-separator slash from an encoded %2F; a long-known problem but not one > that greatly affects most people. > > But combined with (2) that means some other component must choose how to > decode the bytes into Unicode characters. No standard currently specifies > what encoding to use, it is not typically configuarable, and it's certainly > not within reach of the WSGI application. My assumption is that most > applications will want to end up with UTF-8-encoded URLs; other choices are > certainly possible but as we move towards IRI they become less likely. > > > This situation previously affected only Windows users, because NT > environment variables are native Unicode. However, Python 3.0 specifies all > environment variable access is through a Unicode wrapper, and gives no way > to control how that automatic decoding is done, leaving everyone in the same > boat. > > WSGI Amendments_1.0 includes a suggestion for Python 3.0 that environ should > be "decoded from the headers using HTTP standard encodings (i.e. latin-1 + > RFC 2047)", but unfortunately this doesn't quite work: > > 1. for many existing environments the decoding-from-headers charset is out > of reach of the WSGI server/layer and may well not be ISO-8859-1. Even > wsgiref doesn't currently use 8859-1 (see below). > > 2. RFC2047 is not applicable to HTTP headers, which are not really > 822-family headers even though they look just like them. The sub-headers in > eg. a multipart/form-data chunk *are* (probably) proper 822 headers so > RFC2047 could apply, but those headers are already dealt with by the > application or framework, not WSGI. HTTP 1.1 (RFC2616) does refer to RFC2047 > as an encoding mechanism for TEXT and quoted-string, but this makes no sense > as 2047 itself requires embedding in atom-based parsing sequences which > those productions are not (quoted-strings are explicitly disallowed by 2047 > itself). In any case no existing browser attempts to support RFC2047 > encoding rules for any possible interpretation of what 2616 might mean. > > > Something like Luís Bruno's ORIGINAL_PATH_INFO proposal > (http://mail.python.org/pipermail/web-sig/2008-January/003124.html) would be > worth looking at for this IMO. It may be of questionable usefulness if the > only character affected is the slash, but it also happens to solve the > Unicode problem. Obviously whatever it was called it would have to be an > optional additional value in the WSGI environ, as pure CGI servers wouldn't > be able to supply it. Conceivably it might also be possible to have a > standardised mod_rewrite rule to make the variable also available to Apache > CGI scripts, but still this is far from global availability. > > In the meantime I've been looking at how various combinations of servers > deal with this issue, and in what circumstances an application or middleware > can safely recover all possible Unicode input. 'Apache' refers to the > (AFAICT-identical) behaviour of both mod_cgi and mod_wsgi; 'IIS' refers to > IIS with CGI. > > > *** Apache/Posix/Python2 > OK. > > No problem here, it's byte-based all the way through. > > > *** Apache/Posix/Python3: > Dependent on the default encoding. > > Apache puts bytes into the envvars but Python takes them out as unicode. If > the system default encoding happens to be the same as the encoding the WSGI > application wanted we will be OK. Normally the app will want UTF-8; many > Linux distributions do use UTF-8 as the default system encoding but there > are plenty of distros (eg. Debian) and other Unixen that do not. In any case > we are getting a nasty system dependency at deploy time that many webmasters > will not be able to resolve. > > It is sometimes possible to recover mangled characters despite the wrong > decoding having been applied. For example if the system encoding was > ISO-8859-1 or another encoding that maps every byte to a unique Unicode > character, we can encode the Unicode string back to its original bytes, and > thence apply the decoding we actually wanted! If, on the other hand, it's > something like ISO-8859-4, where not all high bytes are mapped at all, we'll > be losing random characters... not good. > > > *** Apache/NT/Python2 > Always unrecoverable data loss. > > Apache on Windows always uses ISO-8859-1 to decode the request path and put > it in the Unicode envvars. This is OK so far, we have Unicode characters > with the same codepoints as the original bytes. However, Python2 needs to > make the envvars available as bytes. It uses the system default encoding; if > that were ISO-8859-1, we'd be OK. > > But it never is. Western European on NT is actually cp1252, whose characters > in the range 0x80 to 0x9F differ from ISO-8859-1. And if the app wants > UTF-8, chances are those characters are going to come up a lot. There is as > far as I know no user-selectable Windows codepage that can map all the > Unicode characters up to U+00FF. > > > *** Apache/NT/Python3 > Wrong, but always recoverable. > > Python retreives the bytes-encoded-into-Unicode-codepoints string directly > from the envvars. If the encoding should have been UTF-8 or something else > other than ISO-8859-1, we can recover the original bytes by re-encoding to > 8859-1, then decoding using the real charset. > > > *** IIS/NT/Python2 > Mostly unrecoverable data loss. > > IIS decodes submitted bytes to Unicode using UTF-8 when it can. But if there > is an invalid UTF-8 sequence in the bytes it will try again using the system > codepage. Python will then re-encode the Unicode envvar using the system > codepage. > > If the app is expecting UTF-8 we can decode what Python gives us using the > system codepage (ie. 'mbcs') and get back any of the submitted characters > that happened to be in this server's system codepage. Other characters may > be replaced by question marks or Windows's best attempts to give us > something useful, which at best may be a character shorn of diacriticals and > at worst something just completely wrong. > > NT's system codepage is never UTF-8, it is not a user-selectable option > never mind the default. We can improve our chances of getting more > characters through by using a character set with a wide repertoire, such as > cp932 (Shift-JIS). But it's still not really proper Unicode support. > > If the app is expecting something non-UTF-8 there's not much hope. Even if > it wanted the same character set as the system codepage, it can't be sure > that the submitted bytes didn't happen to also be a valid UTF-8 sequence, > and thus get mangled by IIS decoding them that way. > > > *** IIS/NT/Python3 > OK, as long as the app wants UTF-8. > > Incoming UTF-8 bytes are reliably converted to Unicode strings by IIS, and > directly read by Python from the envvars. > > If the application didn't want UTF-8 the situation is about as hopeless as > with Python2. > > > *** wsgiref.simple_server/(any)/Python2 > OK. > > Bytes all the way through. > > > *** wsgiref.simple_server/(any)/Python3: > Probably will be OK, as long as the app wants UTF-8. > > simple_server is currently broken in rc2. However judging by the code, it is > using urllib.parse.unquote, which assumes UTF-8, so it'll be fine for apps > that want UTF-8 and hopeless for those that don't. > > > I'd be very interested to hear what other servers are doing in this > situation - nginx? cherrypy's one? - and wonder if any particular behaviour > should be 'blessed'. > > -- > And Clover > mailto:and@... > http://www.doxdesk.com/ > _______________________________________________ > Web-SIG mailing list > Web-SIG@... > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > _______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
|
Dear Benji York,
Thank you very much for letting me to know this.
I am not a programmer but has a demonstration project to complete. How can I easily to follow instructions to implement and test this?
Does it work with Ajax?
I am using Windows Server and IIS. I do not have facility to un-gzip it.
Regards.
David
--- On Fri, 31/10/08, Benji York <benji <at> benjiyork.com> wrote: From: Benji York <benji-N5ZisqgMTFtiLUuM0BA3LQ@public.gmane.org> |
_______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
On Thu, Nov 13, 2008 at 6:40 AM, David Shi <davidgshi@...> wrote: > Dear Benji York, > > Thank you very much for letting me to know this. > > I am not a programmer but has a demonstration project to complete. How can > I easily to follow instructions to implement and test this? I doubt it; zc.async is well documented, but it is only tool. Therefore you can use it to accomplish your goal, but you would have to do a non-trivial amount of programming to address your particular need. > Does it work with Ajax? That question doesn't really apply. -- -- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Web-SIG mailing list Web-SIG@... Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Ian Bicking wrote:
> As it is (in Python 2), you should do something like
> environ['PATH_INFO'].decode('utf8') and it should work.
See the test cases in my original post: this doesn't work universally.
On WinNT platforms PATH_INFO has already gone through a decode/encode
cycle which almost always irretrievably mangles the value.
> My understanding of this suggestion is that latin-1 is a way of
> representing bytes as unicode. In other words, the values will be
> unicode, but that will simply be a lie.
Yes, that would be a sensible approach, but it is not what is actually
happening in any WSGI environment I have tested. For example
wsgiref.simple_server decodes using UTF-8 not 8859-1 — or would do, if
it were working. (It is currently broken in 3.0rc2; I put a hack in to
get it running but I'm not really sure what the current status of
simple_server in 3.0 is.)
> A lot of what you write about has to do with CGI, which is the only
> place WSGI interacts with os.environ. CGI is really an aspect of the
> CGI to WSGI adapter (like wsgiref.handlers.CGIHandler), and not the WSGI
> spec itself.
Indeed, but we naturally have to take into account implementability on
CGI. If a WSGI spec *requires* PATH_INFO to have been obtained using
8859-1 decoding — or UTF-8, which is the other sensible option given
that most URIs today are UTF-8 — then there cannot be a fully-compliant
CGI-to-WSGI wrapper. Perhaps it's not the big issue it was when WSGI was
first getting off the ground, but IMO it's still important.
> Personally I'm more inclined to set up a policy on the WSGI server
> itself with respect to the encoding, and then use real unicode
> characters.
I think we are stuck with Unicode environ at this point, given the CGI
issue. But applications do need to know about the encoding in use,
because they will (typically) be generating their own links. So an
optional way to get that information to the application would be
advantageous.
I'm now of the opinion that the best way to do this is to standardise
Apache's ‘REQUEST_URI’ as an optional environ item. This header is
pre-URI-decoding, containing only %-sequences and not real high bytes,
so it can be decoded to Unicode using any old charset without worry.
An application wanting to support Unicode URIs (or encoded slashes in
URIs*) could then sniff for REQUEST_URI and use it in preference to
PATH_INFO where available. This is a bit more work for the application,
but it should generally be handled transparently by a library/framework
and supporting PATH_INFO in a portable fashion already has warts thanks
to IIS's bugs, so the situation is not much worse than it already is.
And of course we get support through mod_cgi and mod_wsgi automatically,
so Graham doesn't have to do anything. 
Graham Dumpleton wrote:
> I can't really remember what the outcome of the discussion was.
Not too much outcome really, unfortunately! You concluded:
> there possibly still is an open question there on how
> encoding of non ascii characters works in practice. We just need to
> do some actual tests to see what happens and whether there is a problem.
...to which the answer is — judging by the results posted — probably
“yes”, I'm afraid!
--
--
And Clover
mailto:and <at> doxdesk.com
http://www.doxdesk.com/
_______________________________________________
Web-SIG mailing list
Web-SIG <at> python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
RSS Feed4 | |
|---|---|
4 | |
1 | |
4 | |
2 | |
1 | |
8 | |
16 | |
15 | |
8 | |
16 | |
37 | |
3 | |
2 | |
1 | |
18 | |
7 | |
1 | |
3 | |
55 | |
6 | |
14 | |
218 | |
7 | |
17 | |
34 | |
129 | |
22 | |
76 | |
23 | |
5 | |
78 | |
33 | |
1 | |
13 | |
33 | |
54 | |
16 | |
250 | |
50 | |
18 | |
57 | |
23 | |
88 | |
30 | |
1 | |
17 | |
19 | |
47 | |
2 | |
14 | |
16 | |
92 | |
16 | |
50 | |
27 | |
98 | |
81 | |
92 | |
124 | |
55 | |
154 | |
13 | |
16 | |
23 | |
50 | |
9 | |
16 | |
155 | |
11 | |
24 | |
56 | |
89 | |
45 | |
33 | |
8 | |
2 | |
9 | |
26 | |
50 | |
23 | |
199 | |
68 | |
81 | |
17 | |
17 | |
23 | |
123 | |
93 | |
77 | |
74 | |
167 | |
26 | |
20 | |
19 | |
25 | |
89 | |
85 | |
200 | |
218 | |
1 | |
1 | |
2 | |
19 | |
2 | |
61 | |
51 | |
79 | |
6 | |
3 | |
4 |
