17682 2008-03-05 11:02:38 -0800 XHR setRequestHeader("connection", "close") is bogusly rejected 2008-03-17 13:07:21 -0700 1 1 1 Unclassified WebKit XML 528+ (Nightly build) All All RESOLVED WONTFIX InRadar P2 Normal --- 1 fishd webkit-unassigned ap gavin.sharp jchaffraix oldest_to_newest 72817 0 fishd 2008-03-05 11:02:38 -0800 XHR setRequestHeader("connection", "close") is bogusly rejected This is used by Gmail for example to request a non-persistent connection. This is a standard mechanism used by web apps, and the intent is to not have the XHR connection not count against the browser's limit on the maximum number of persistent connections per host that it will open at any given time. It looks like Gmail uses this for a request that does not have an immediate response. The server only responds to the request when it has some data to send to the client. As a result, the connection is open for a long time, and therefore it does not make any sense to count it as a persistent connection. Other browsers (FF2 at least) do not prevent the "connection: close" header from being set. I see that http://www.w3.org/TR/XMLHttpRequest/ recommends blocking the "connection" request header, but I think it is a very poor recommendation. 72819 1 ap 2008-03-05 11:19:31 -0800 Are you sure this helps to avoid the running into the two-connection limit? I would expect the network layer of any browser to close idle connections when new requests are made. 72820 2 fishd 2008-03-05 11:31:26 -0800 I wasn't referring to idle connections..... Imagine you have 3 requests to host A. If all requests take a long time to complete, then one of the requests will be delayed. However, if that third request is marked as not opening a persistent connection, then there is no reason for the browser to delay issuing the request (i.e., opening a new connection is ok). By setting a "connection: close" request header, the request is indicating that the connection should not be made persistent. This is documented in RFC 2616. 72828 3 ap 2008-03-05 12:17:54 -0800 As for Firefox 3: <http://lxr.mozilla.org/seamonkey/source/content/base/src/nsXMLHttpRequest.cpp#2403> (In reply to comment #2) > Imagine you have 3 requests to host A. If all requests take a long time to > complete, then one of the requests will be delayed. However, if that third > request is marked as not opening a persistent connection, then there is no > reason for the browser to delay issuing the request (i.e., opening a new > connection is ok). Do you have a test that shows that the third request is delayed in WebKit? I can make one myself, but if you already have a proof, we won't have to duplicate the effort. 72953 4 mrowe 2008-03-06 17:13:53 -0800 A visitor to #webkit mentioned that the Keep-Alive header is also rejected. 72954 5 mrowe 2008-03-06 17:14:05 -0800 <rdar://problem/5785951> 72955 6 fishd 2008-03-06 17:45:17 -0800 It seems OK to reject the keep-alive header. That is not a standard request header. Also, it should probably not be allowed for XHR to request keep-alive semantics since the browser cannot promise that. The browser can promise that it will not reuse the connection though ;-) Alexey, my test case was Gmail. I was using the web inspector and noticed that a warning appeared in the error console about "connection" being an illegal request header. 72969 7 ap 2008-03-06 22:26:08 -0800 Yes, I understood that these warnings came from GMail. But was there any negative effect on behavior? Were connections delayed indeed? 73035 8 fishd 2008-03-07 15:06:04 -0800 Well, from what I can tell, the XHR request in question is for the host mail.google.com. That means that it is clogging a persistent connection, leaving one less connection free for other resources. I can imagine that this has a negative impact on performance. Since this XHR request is the only such long-lived request, it clearly doesn't cause a complete blockage :-) 73037 9 mjs 2008-03-07 15:11:15 -0800 We can use an attempt to set "Connection: close" as a hint not to reuse the connection, but I don't think it is correct to send it along as-is, nor would sending it along necessarily make the network layer decide that the connection doesn't count towards the connection limit. If we wanted a hint that says "this may be a long-lived connection, so don't block other loads waiting for it", then perhaps something more explicit (like a property on the XHR object) would make more sense. Or perhaps we could always treat XHR this way. IE8b1 raised their connection limit to 6, and the HTTPbis Working Group at the IETF is considering eliminating the connection limit from the spec entirely. Note that CFNetwork's current connection limit is 4, so a single long-lived request is unlikely to block progress, but we can still make improvements here. 73042 10 fishd 2008-03-07 15:42:11 -0800 > We can use an attempt to set "Connection: close" as a hint not to reuse the > connection, but I don't think it is correct to send it along as-is, nor would > sending it along necessarily make the network layer decide that the connection > doesn't count towards the connection limit. > > If we wanted a hint that says "this may be a long-lived connection, so don't > block other loads waiting for it", then perhaps something more explicit (like a > property on the XHR object) would make more sense. Or perhaps we could always > treat XHR this way. The behavior of existing browsers is to pass it along and to respect it on the client side (in the manner I described). I think it is a compat bug that WebKit does not work this way. I understand that this could involve changing more than just WebKit... CFNetwork might need changes in the case of Safari. If the UA's network stack does not recognize this request header as a "hint", then at least the origin server or proxy server would understand it and should properly respond w/ "connection: close", which should cause the UA's network stack to stop counting the connection against the max persistent connections per host limit. So, sending this header seems like a good thing to me. Why do you think it should not be sent? 73043 11 mjs 2008-03-07 15:47:24 -0800 By the time the origin server sends the response, it's too late to stop counting the request against the connection limit, since by assumption by then it has already been open for a while. It is better to decide this up front. I am also not sure that closing the connection after the response needs to be tied to not counting towards the connection limit. If there are requests for the server queued up at the time the response comes back, it would be valid and indeed good for the UA to reuse that connection if it can. So in conclusion, I think it may be a better design to make XHR-initiated requests always bypass the connection limit. 73044 12 mjs 2008-03-07 15:55:42 -0800 I don't think passing along the header will be a practical issue at all if we advise the network stack in whatever way is appropriate not to count any XHR-initiated requests against the connection limit. Actually sending a "Connection: close" header over the wire does not seem necessary to achieve the desired goal of bypassing the connection limit, just an accidental side effect. However, this may be the appropriate way to advise some network stacks to bypass the connection limit. 73107 13 fishd 2008-03-08 21:43:39 -0800 (In reply to comment #11) > By the time the origin server sends the response, it's too late to stop > counting the request against the connection limit, since by assumption by then > it has already been open for a while. The origin server can send its response in chunks. The first chunk could come immediately and only contain the response headers. Subsequent chunks could come much later. If the UA sees "connection: close" in that initial payload, then it could recognize that the connection will not be persistent, and therefore it can open a new connection if there are pending requests. (This is AFAIK the typical behavior of HTTP/1.1 clients.) Anyways, this topic is a tangent. > So in conclusion, I think it may be a better design to make XHR-initiated > requests always bypass the connection limit. This could be risky. I have heard that some routers have trouble if they receive too many SYN packets at once. Not having a connection limit might force web apps to do their own connection limiting, which could be problematic. I wish I had a reference for this anecdote :-/ Again, the point of this bug is to simply match existing browser behavior. It is a compat bug. If there is a better long-term solution, involving nicer APIs, then that's great, but I don't think it is mutually exclusive with supporting the existing "API" for creating a XHR request that is not counted against the browser's persistent connection limit. 73177 14 19629 ap 2008-03-10 02:07:46 -0700 Created attachment 19629 test case > Again, the point of this bug is to simply match existing browser behavior. It > is a compat bug. I have made a test now, and I do not see "Connection: close" having the described effect on Firefox 2.0.0.9. This "non-persistent" request is still delayed until slow requests are finished. It is possible that I got my Apache configuration (or something else) wrong, so I encourage you to check my results. 127.0.0.1 - - [10/Mar/2008:12:03:16 +0300] "GET /slow-resource.html HTTP/1.1" 200 1197 127.0.0.1 - - [10/Mar/2008:12:03:16 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:19 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:22 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:25 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:28 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:31 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:34 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:37 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:40 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:43 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 127.0.0.1 - - [10/Mar/2008:12:03:46 +0300] "GET / HTTP/1.1" 404 309 ^^ That's the request with "Connection: close" set. 127.0.0.1 - - [10/Mar/2008:12:03:46 +0300] "GET /slow-resource.pl HTTP/1.1" 200 5 73275 15 fishd 2008-03-10 19:16:28 -0700 Alexey, your test is flawed. Try opening N different URLs. You are seeing the requests get serialized around access to the cache. 73293 16 19658 ap 2008-03-11 00:59:38 -0700 Created attachment 19658 test case (tweaked for Firefox 2 compatibility) Heh, actually the flaw was due to a bug in Firefox 2 - it was making sync requests instead of async if the third parameter to open() was omitted. With a corrected test, I can confirm that Firefox 2 does handle "Connection: close" as described above. According to results given in a parallel public-webapi discussion, it is the only browser that does so. 73434 17 fishd 2008-03-11 23:41:41 -0700 > Heh, actually the flaw was due to a bug in Firefox 2 - it was making sync > requests instead of async if the third parameter to open() was omitted. Yes, that was also a problem. 74141 18 fishd 2008-03-17 13:07:21 -0700 based on the discussion from public-webapi@w3.org, WONTFIX seems appropriate :-( 19629 2008-03-10 02:07:46 -0700 2008-03-11 00:59:38 -0700 test case slow-resource.zip application/zip 1498 ap UEsDBBQACAAIABlgajgAAAAAAAAAAAAAAAASABAAc2xvdy1yZXNvdXJjZS5odG1sVVgMANP41EfC +NRH9QH1Ac1UsU7DMBTc+xVPnhwFUlhJKENV6AAMlIENpclra8m1U9uhqRD/zkvahKQtVSUWPFh2 fHe+d3lyNNXpZtCLbGJE5gY9oPERG0i0slri+xKtjedo4RZSneRLVC5IDMYORxLLHWe5ZF5YERtE KRrEWYYqHS6ETPm+3I5QTbNcJU5oBVLP+Q7gVSef1VxbEg6XJ2xIUdsoRwnuONijvWLhnnWKzYUt 7r7Zjk4pvMN+9Zq4RNgsDa62m5k2wAU5vgrJD0RwTQvfF16rLgITQOEa3p4ex85lL7jK0bqwjQhU vpyiIaDoftdki7OH0Su7AGalXl8atDo3CQaZbKdRgRUVnm6so+qTRazmSIJ19rwgV9UPYBPSIYLN KAUEBj7wAu6gCFxs5uhqMz4dMbgBxrxyfUT9kFpBJiVkS/RCyrDt0VLMvJvu6YQOUujXZW/l3A49 ppvRcDbUSmFVcQlOpLbYJpyb0X1s3U9Gf6u9XfeZFTf9QB11PIbfmuG/N0I7jKhfP0pRf/tKfQNQ SwcIlm2edYcBAACtBAAAUEsDBAoAAAAAACRgajgAAAAAAAAAAAAAAAAJABAAX19NQUNPU1gvVVgM ANP41EfT+NRH9QH1AVBLAwQUAAgACAAZYGo4AAAAAAAAAAAAAAAAHQAQAF9fTUFDT1NYLy5fc2xv dy1yZXNvdXJjZS5odG1sVVgMANP41EfC+NRH9QH1AWNgFWNnYGJg8E1MVvAPVohQgAKQGAMnEBsB sQIQg/hBQMwQ4hoRohiUnMGAAwAAUEsHCJfGXMIvAAAAUgAAAFBLAwQUAAgACADWXGo4AAAAAAAA AAAAAAAAEAAQAHNsb3ctcmVzb3VyY2UucGxVWAwA0/jUR5Tz1Ef1AfUBTY9BS8QwFITv+RXjrgeF hqYueEjxtF086QrGm5dsfbWBbBqSV13BH++2oBbmMPDNPOatL8oxp/LgQhkpechPIdbo/Jh7cE84 jF1HKcN2TAlk2x4xucAik6eWcfVsmv2Lua7F5TfuUNVCzByr7RCYAkvzFUmD6cRl9NaF17CqfzO7 U3SJsobpxwKqQkMtbpTaoLrVSp2F+wezbGzPC0hOt9PgNcIgMw+Jism1EytwHDPLRB/WuzfLtGw/ Jft+tPovvGSzF9kTRWz+32j2j7sZ/QBQSwcIF1JUZdEAAAAqAQAAUEsDBBQACAAIANZcajgAAAAA AAAAAAAAAAAbABAAX19NQUNPU1gvLl9zbG93LXJlc291cmNlLnBsVVgMANP41EeU89RH9QH1AWNg FWNnYGJg8E1MVvAPVohQgAKQGAMnEBsBsQIQg/hBQMwQ4hoRohiUnMGAAwAAUEsHCJfGXMIvAAAA UgAAAFBLAQIVAxQACAAIABlgajiWbZ51hwEAAK0EAAASAAwAAAAAAAAAAECkgQAAAABzbG93LXJl c291cmNlLmh0bWxVWAgA0/jUR8L41EdQSwECFQMKAAAAAAAkYGo4AAAAAAAAAAAAAAAACQAMAAAA AAAAAABA/UHXAQAAX19NQUNPU1gvVVgIANP41EfT+NRHUEsBAhUDFAAIAAgAGWBqOJfGXMIvAAAA UgAAAB0ADAAAAAAAAAAAQKSBDgIAAF9fTUFDT1NYLy5fc2xvdy1yZXNvdXJjZS5odG1sVVgIANP4 1EfC+NRHUEsBAhUDFAAIAAgA1lxqOBdSVGXRAAAAKgEAABAADAAAAAAAAAAAQO2BmAIAAHNsb3ct cmVzb3VyY2UucGxVWAgA0/jUR5Tz1EdQSwECFQMUAAgACADWXGo4l8Zcwi8AAABSAAAAGwAMAAAA AAAAAABApIG3AwAAX19NQUNPU1gvLl9zbG93LXJlc291cmNlLnBsVVgIANP41EeU89RHUEsFBgAA AAAFAAUAhQEAAD8EAAAAAA== 19658 2008-03-11 00:59:38 -0700 2008-03-11 00:59:38 -0700 test case (tweaked for Firefox 2 compatibility) slow-resource.zip application/zip 4468 ap UEsDBBQACAAIADdWazgAAAAAAAAAAAAAAAASABAAc2xvdy1yZXNvdXJjZS5odG1sVVgMAHw71kea OdZH9QH1AZ3Vz2+CMBQH8Lt/RdMTZBtGfl10Xoybh22H6WG3hcGbktQWaZkas/99BZGpKy8LHEho +977fnph9CGS/bg3knGeZmrcI/r5inISCy4Fg/c1SBktQZJ7koi4WANXTpxDpGDKoPyyaMGoPawK mxNlUyfKMuDJZJWyxLpuVxdUr8+CxyoVnDCxtOoDdrVzqN6nSKmCNRKDpacY5VMevkhwVbaAnXoR CTQDz2qvw170KRvXZ797zXXlsBnobBy25O35aaZU9gqbAqQ6niy3HaGbWPRxuqC3hEomtnc5SFHk MQycjOlFlRdgnxdwHTXZS6XzxquIL0GPON2WtbPJoboyOte9dIXMdG4gA2Koo+Tm2LPamZc79lAD mllSAy09/Fzk4iIXEbkmkdtR5CIit0XkGkUeLvIQkWcSeR1FHiLyWkSeUeTjIh8R+SaR31HkIyK/ ReQbRQEuChBRYBIFHUUBIgpaRIFRFOKiEBGFJlHYURQiorBFFF6K9AqOubT0/2TX7VRdM9MDIbfo RHAOVfKyJGZCAj0r+K/1IZLq19oubYE2zlH/9C8c9Y8/xx9QSwcIer0abKsBAAAkBwAAUEsDBAoA AAAAADhXazgAAAAAAAAAAAAAAAAJABAAX19NQUNPU1gvVVgMAHw71kd8O9ZH9QH1AVBLAwQUAAgA CAA3Vms4AAAAAAAAAAAAAAAAHQAQAF9fTUFDT1NYLy5fc2xvdy1yZXNvdXJjZS5odG1sVVgMAHw7 1keaOdZH9QH1AWNgFWNnYGJg8E1MVvAPVohQgAKQGAMnEBsBsQIQg/hBQMwQ4hoRohiUnMGAAwAA UEsHCJfGXMIvAAAAUgAAAFBLAwQUAAgACADWXGo4AAAAAAAAAAAAAAAAEQAQAHNsb3ctcmVzb3Vy Y2UxLnBsVVgMAHw71keU89RH9QH1AU2PQUvEMBSE7/kV464HhYamLnhI8bRdPOkKxpuXbH21gWwa klddwR/vtqAW5jDwzTzmrS/KMafy4EIZKXnITyHW6PyYe3BPOIxdRynDdkwJZNseMbnAIpOnlnH1 bJr9i7muxeU37lDVQswcq+0QmAJL8xVJg+nEZfTWhdewqn8zu1N0ibKG6ccCqkJDLW6U2qC61Uqd hfsHs2xszwtITrfT4DXCIDMPiYrJtRMrcBwzy0Qf1rs3y7RsPyX7frT6L7xksxfZE0Vs/t9o9o+7 Gf0AUEsHCBdSVGXRAAAAKgEAAFBLAwQUAAgACADWXGo4AAAAAAAAAAAAAAAAHAAQAF9fTUFDT1NY Ly5fc2xvdy1yZXNvdXJjZTEucGxVWAwAfDvWR5Tz1Ef1AfUBY2AVY2dgYmDwTUxW8A9WiFCAApAY AycQGwGxAhCD+EFAzBDiGhGiGJScwYADAABQSwcIl8Zcwi8AAABSAAAAUEsDBBQACAAIANZcajgA AAAAAAAAAAAAAAARABAAc2xvdy1yZXNvdXJjZTIucGxVWAwAfDvWR5Tz1Ef1AfUBTY9BS8QwFITv +RXjrgeFhqYueEjxtF086QrGm5dsfbWBbBqSV13BH++2oBbmMPDNPOatL8oxp/LgQhkpechPIdbo /Jh7cE84jF1HKcN2TAlk2x4xucAik6eWcfVsmv2Lua7F5TfuUNVCzByr7RCYAkvzFUmD6cRl9NaF 17CqfzO7U3SJsobpxwKqQkMtbpTaoLrVSp2F+wezbGzPC0hOt9PgNcIgMw+Jism1EytwHDPLRB/W uzfLtGw/Jft+tPovvGSzF9kTRWz+32j2j7sZ/QBQSwcIF1JUZdEAAAAqAQAAUEsDBBQACAAIANZc ajgAAAAAAAAAAAAAAAAcABAAX19NQUNPU1gvLl9zbG93LXJlc291cmNlMi5wbFVYDAB8O9ZHlPPU R/UB9QFjYBVjZ2BiYPBNTFbwD1aIUIACkBgDJxAbAbECEIP4QUDMEOIaEaIYlJzBgAMAAFBLBwiX xlzCLwAAAFIAAABQSwMEFAAIAAgA1lxqOAAAAAAAAAAAAAAAABEAEABzbG93LXJlc291cmNlMy5w bFVYDAB8O9ZHlPPUR/UB9QFNj0FLxDAUhO/5FeOuB4WGpi54SPG0XTzpCsabl2x9tYFsGpJXXcEf 77agFuYw8M085q0vyjGn8uBCGSl5yE8h1uj8mHtwTziMXUcpw3ZMCWTbHjG5wCKTp5Zx9Wya/Yu5 rsXlN+5Q1ULMHKvtEJgCS/MVSYPpxGX01oXXsKp/M7tTdImyhunHAqpCQy1ulNqgutVKnYX7B7Ns bM8LSE630+A1wiAzD4mKybUTK3AcM8tEH9a7N8u0bD8l+360+i+8ZLMX2RNFbP7faPaPuxn9AFBL BwgXUlRl0QAAACoBAABQSwMEFAAIAAgA1lxqOAAAAAAAAAAAAAAAABwAEABfX01BQ09TWC8uX3Ns b3ctcmVzb3VyY2UzLnBsVVgMAHw71keU89RH9QH1AWNgFWNnYGJg8E1MVvAPVohQgAKQGAMnEBsB sQIQg/hBQMwQ4hoRohiUnMGAAwAAUEsHCJfGXMIvAAAAUgAAAFBLAwQUAAgACADWXGo4AAAAAAAA AAAAAAAAEQAQAHNsb3ctcmVzb3VyY2U0LnBsVVgMAHw71keU89RH9QH1AU2PQUvEMBSE7/kV464H hYamLnhI8bRdPOkKxpuXbH21gWwaklddwR/vtqAW5jDwzTzmrS/KMafy4EIZKXnITyHW6PyYe3BP OIxdRynDdkwJZNseMbnAIpOnlnH1bJr9i7muxeU37lDVQswcq+0QmAJL8xVJg+nEZfTWhdewqn8z u1N0ibKG6ccCqkJDLW6U2qC61UqdhfsHs2xszwtITrfT4DXCIDMPiYrJtRMrcBwzy0Qf1rs3y7Rs PyX7frT6L7xksxfZE0Vs/t9o9o+7Gf0AUEsHCBdSVGXRAAAAKgEAAFBLAwQUAAgACADWXGo4AAAA AAAAAAAAAAAAHAAQAF9fTUFDT1NYLy5fc2xvdy1yZXNvdXJjZTQucGxVWAwAfDvWR5Tz1Ef1AfUB Y2AVY2dgYmDwTUxW8A9WiFCAApAYAycQGwGxAhCD+EFAzBDiGhGiGJScwYADAABQSwcIl8Zcwi8A AABSAAAAUEsDBBQACAAIANZcajgAAAAAAAAAAAAAAAARABAAc2xvdy1yZXNvdXJjZTUucGxVWAwA fDvWR5Tz1Ef1AfUBTY9BS8QwFITv+RXjrgeFhqYueEjxtF086QrGm5dsfbWBbBqSV13BH++2oBbm MPDNPOatL8oxp/LgQhkpechPIdbo/Jh7cE84jF1HKcN2TAlk2x4xucAik6eWcfVsmv2Lua7F5Tfu UNVCzByr7RCYAkvzFUmD6cRl9NaF17CqfzO7U3SJsobpxwKqQkMtbpTaoLrVSp2F+wezbGzPC0hO t9PgNcIgMw+Jism1EytwHDPLRB/WuzfLtGw/Jft+tPovvGSzF9kTRWz+32j2j7sZ/QBQSwcIF1JU ZdEAAAAqAQAAUEsDBBQACAAIANZcajgAAAAAAAAAAAAAAAAcABAAX19NQUNPU1gvLl9zbG93LXJl c291cmNlNS5wbFVYDAB8O9ZHlPPUR/UB9QFjYBVjZ2BiYPBNTFbwD1aIUIACkBgDJxAbAbECEIP4 QUDMEOIaEaIYlJzBgAMAAFBLBwiXxlzCLwAAAFIAAABQSwMEFAAIAAgA1lxqOAAAAAAAAAAAAAAA ABEAEABzbG93LXJlc291cmNlNi5wbFVYDAB8O9ZHlPPUR/UB9QFNj0FLxDAUhO/5FeOuB4WGpi54 SPG0XTzpCsabl2x9tYFsGpJXXcEf77agFuYw8M085q0vyjGn8uBCGSl5yE8h1uj8mHtwTziMXUcp w3ZMCWTbHjG5wCKTp5Zx9Wya/Yu5rsXlN+5Q1ULMHKvtEJgCS/MVSYPpxGX01oXXsKp/M7tTdImy hunHAqpCQy1ulNqgutVKnYX7B7NsbM8LSE630+A1wiAzD4mKybUTK3AcM8tEH9a7N8u0bD8l+360 +i+8ZLMX2RNFbP7faPaPuxn9AFBLBwgXUlRl0QAAACoBAABQSwMEFAAIAAgA1lxqOAAAAAAAAAAA AAAAABwAEABfX01BQ09TWC8uX3Nsb3ctcmVzb3VyY2U2LnBsVVgMAHw71keU89RH9QH1AWNgFWNn YGJg8E1MVvAPVohQgAKQGAMnEBsBsQIQg/hBQMwQ4hoRohiUnMGAAwAAUEsHCJfGXMIvAAAAUgAA AFBLAQIVAxQACAAIADdWazh6vRpsqwEAACQHAAASAAwAAAAAAAAAAECkgQAAAABzbG93LXJlc291 cmNlLmh0bWxVWAgAfDvWR5o51kdQSwECFQMKAAAAAAA4V2s4AAAAAAAAAAAAAAAACQAMAAAAAAAA AABA/UH7AQAAX19NQUNPU1gvVVgIAHw71kd8O9ZHUEsBAhUDFAAIAAgAN1ZrOJfGXMIvAAAAUgAA AB0ADAAAAAAAAAAAQKSBMgIAAF9fTUFDT1NYLy5fc2xvdy1yZXNvdXJjZS5odG1sVVgIAHw71kea OdZHUEsBAhUDFAAIAAgA1lxqOBdSVGXRAAAAKgEAABEADAAAAAAAAAAAQO2BvAIAAHNsb3ctcmVz b3VyY2UxLnBsVVgIAHw71keU89RHUEsBAhUDFAAIAAgA1lxqOJfGXMIvAAAAUgAAABwADAAAAAAA AAAAQKSB3AMAAF9fTUFDT1NYLy5fc2xvdy1yZXNvdXJjZTEucGxVWAgAfDvWR5Tz1EdQSwECFQMU AAgACADWXGo4F1JUZdEAAAAqAQAAEQAMAAAAAAAAAABA7YFlBAAAc2xvdy1yZXNvdXJjZTIucGxV WAgAfDvWR5Tz1EdQSwECFQMUAAgACADWXGo4l8Zcwi8AAABSAAAAHAAMAAAAAAAAAABApIGFBQAA X19NQUNPU1gvLl9zbG93LXJlc291cmNlMi5wbFVYCAB8O9ZHlPPUR1BLAQIVAxQACAAIANZcajgX UlRl0QAAACoBAAARAAwAAAAAAAAAAEDtgQ4GAABzbG93LXJlc291cmNlMy5wbFVYCAB8O9ZHlPPU R1BLAQIVAxQACAAIANZcajiXxlzCLwAAAFIAAAAcAAwAAAAAAAAAAECkgS4HAABfX01BQ09TWC8u X3Nsb3ctcmVzb3VyY2UzLnBsVVgIAHw71keU89RHUEsBAhUDFAAIAAgA1lxqOBdSVGXRAAAAKgEA ABEADAAAAAAAAAAAQO2BtwcAAHNsb3ctcmVzb3VyY2U0LnBsVVgIAHw71keU89RHUEsBAhUDFAAI AAgA1lxqOJfGXMIvAAAAUgAAABwADAAAAAAAAAAAQKSB1wgAAF9fTUFDT1NYLy5fc2xvdy1yZXNv dXJjZTQucGxVWAgAfDvWR5Tz1EdQSwECFQMUAAgACADWXGo4F1JUZdEAAAAqAQAAEQAMAAAAAAAA AABA7YFgCQAAc2xvdy1yZXNvdXJjZTUucGxVWAgAfDvWR5Tz1EdQSwECFQMUAAgACADWXGo4l8Zc wi8AAABSAAAAHAAMAAAAAAAAAABApIGACgAAX19NQUNPU1gvLl9zbG93LXJlc291cmNlNS5wbFVY CAB8O9ZHlPPUR1BLAQIVAxQACAAIANZcajgXUlRl0QAAACoBAAARAAwAAAAAAAAAAEDtgQkLAABz bG93LXJlc291cmNlNi5wbFVYCAB8O9ZHlPPUR1BLAQIVAxQACAAIANZcajiXxlzCLwAAAFIAAAAc AAwAAAAAAAAAAECkgSkMAABfX01BQ09TWC8uX3Nsb3ctcmVzb3VyY2U2LnBsVVgIAHw71keU89RH UEsFBgAAAAAPAA8ArAQAALIMAAAAAA==