From kfm-devel Fri Jul 13 18:49:20 2012 From: Dawit A Date: Fri, 13 Jul 2012 18:49:20 +0000 To: kfm-devel Subject: Re: Using KIO to retrive HTTP Headers [GSoC student help request] Message-Id: X-MARC-Message: https://marc.info/?l=kfm-devel&m=134220569306372 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--f46d0446312c1d7be804c4ba8cf6" --f46d0446312c1d7be804c4ba8cf6 Content-Type: multipart/alternative; boundary=f46d0446312c1d7be204c4ba8cf4 --f46d0446312c1d7be204c4ba8cf4 Content-Type: text/plain; charset=UTF-8 Ahh... My fault. I should not have taken back what I said in point #1. It is indeed the case that the "HTTP-Headers" meta-data is NOT set when the redirection signal is emitted by kio_http. However, that is not a problem. Since internal redirection handling is disabled, you get a result signal right after the redirection signal. That is where you need to look for the headers. See the changes in attached files. On Fri, Jul 13, 2012 at 12:44 PM, Aish Raj Dahal wrote: > On Fri, Jul 13, 2012 at 8:18 PM, Dawit A wrote: > > > > > > On Fri, Jul 13, 2012 at 2:41 AM, Dawit A wrote: > >> > >> > >> > >> On Thu, Jul 12, 2012 at 11:16 PM, Aish Raj Dahal < > dahalaishraj@gmail.com> > >> wrote: > >>> > >>> On Thu, Jul 12, 2012 at 9:09 PM, David Faure wrote: > >>> > On Wednesday 11 July 2012 11:53:51 Aish Raj Dahal wrote: > >>> >> 1) Case One : When mimetype signal emitted by KIO::TransferJob is > used > >>> >> > >>> >> In order to clarify more, let me take an example file > >>> >> > >>> >> > https://github.com/ardahal/kio-learner/blob/ard-dev/metalinkHttp/metalinkHtt > >>> >> p.cpp . The given file uses the mimetype signal (at line 44) to get > >>> >> the > >>> >> headers as soon as the mimetype is emitted. The catch is, since we > do > >>> >> no want the redirected HTTP headers but instead want the original > HTTP > >>> >> headers, setRedirectionHandlingEnabled has been set to false. This > >>> >> program when run, does not emit the mimetype signal as all, and as a > >>> >> result the qDebugs at line 51 and 52 are never executed . This > >>> >> behavior is seen not only for URLs which redirect (like > >>> >> http://www.example.com ) but also for URLs which have no > redirection > >>> >> (like http://www.google.com.np) . > >>> > > >>> > This is the part that makes no sense to me ;-) > >>> > > >>> > redirectionHandlingEnabled is a KIO::SimpleJob setting, the slave has > >>> > no idea > >>> > about that setting. If there's no redirection, then none of the code > in > >>> > simplejob that checks for redirectionHandlingEnabled actually runs. > >>> > So it can't possibly make any difference for a URL without > redirection. > >>> > > >>> > I think your testcase is a bit wrong: http://www.google.com.np > >>> > redirects. I > >>> > can see it in the konqueror debug output: > >>> > > >>> > KonqRun::slotRedirection: KUrl("http://www.google.com.np") -> > >>> > KUrl("http://www.google.com.np/") > >>> > > >>> > So if you want to test a URL that doesn't redirect, add the trailing > >>> > slash > >>> > upfront. > >>> > > >>> > If you can confirm this, then we'll be down to: no http headers > emitted > >>> > when a > >>> > redirection happens, which would be a kio_http issue. Dawit? > >>> > > >>> > >>> Thanks a lot for the heads up about the test case :-) > >>> > >>> It does indeed run well as expected with > >>> KUrl("http://www.google.com.np/") as the test URL. However for those > >>> URLs that do have redirection, no headers were emitted. > >>> > >>> Once again, thanks a lot. > >> > >> > >> I will try and clarify some things as much as I can: > >> > >> #1. Without some changes in kio_http, you will never see redirection > >> headers received from HTTP server. This can probably be addressed by > >> delaying the redirection request until after the HTTP headers have been > set. > >> However, the last time I attempted to fix this, it caused a regression. > See > >> bug#150904. > >> > >> > >> #2. When a redirection is requested, kio_http will never emit mimeType > >> signal because it is not yet known. This should be very obvious because > a > >> redirection request is the server telling us the actual location of the > >> content we just requested. As such connecting to KIO's mimeType signal > for > >> such circumstances is of no use. > >> > >> #3. If you do setRedirectionHandlingEnabled(false) in order to handle > >> redirections yourself, instead of KIO, then you have to connect to KIO's > >> redirect signal and retrieve the redirect URL. IOW, you have to do the > same > >> thing you are doing in your "output" function from the slot connected > to the > >> redirection signals. > >> > >> However, I suspect what you want to do is get any and all headers > >> including those that have to do with redirection requests. If so, then > we > >> have to find a way for kio_http to set the HTTP headers before sending > the > >> redirection request without causing a regression. > > > > > > Actually I take back what I said in #1 and the last paragraph. I just did > > some testing and you can indeed retrieve the redirection headers by > simply > > connecting to KIO::TransferJob's redirection signal if you disable the > > internal handling of redirections. All you have to do is check for the > > "HTTP-Headers" meta-data in the slot connected you connected to the > > redirection signal. > > > > Also, although there are two redirection signals, "redirection" and > > "permanentRedirection", you need only connect to the "redirection" unless > > you want to keep track of permanent redirections. > > > > > Thank you very much for looking into the issue. > > Now, as you've suggested using KIO::TransferJob's redirection signal > to connect to a slot and then query for "HTTP-Headers" metadata , I've > faced an issue. > Before I get to the issue here is the pastebin of what I'd doing to > test it http://paste.kde.org/517220/42196913/ . > The issue is that although I am able to verify the redirection URL (if > the site was redirecting of course), querying the KIO::Job for > "HTTP-Headers" metadata keys left me with a QString("") for result. > I've tried testing several URLs and had the same issue (which is quite > strange). I've also tried by setting as well as unsetting the > PropagateHttpHeader metadeta keys, which again had no effect on the > result. > > I hope you'll look into this matter and provide your valuable guidance. > > Thanks once again. > > Regards, > Aish Raj Dahal > --f46d0446312c1d7be204c4ba8cf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ahh... My fault. I should not have taken back what I said in point #1. It i= s indeed the case that the "HTTP-Headers" meta-data is NOT set wh= en the redirection signal is emitted by kio_http. However, that is not a pr= oblem. Since internal redirection handling is disabled, you get a result si= gnal right after the redirection signal. That is where you need to look for= the headers. See the changes in attached files.


On Fri, Jul 13, 2012 at 12:44 PM, Aish Raj Dahal &= lt;dahalaishraj= @gmail.com> wrote:
On F= ri, Jul 13, 2012 at 8:18 PM, Dawit A <= adawit@kde.org> wrote:
>
>
> On Fri, Jul 13, 2012 at 2:41 AM, Dawit A <adawit@kde.org> wrote:
>>
>>
>>
>> On Thu, Jul 12, 2012 at 11:16 PM, Aish Raj Dahal <dahalaishraj@gmail.com>
>> wrote:
>>>
>>> On Thu, Jul 12, 2012 at 9:09 PM, David Faure <faure@kde.org> wrote:
>>> > On Wednesday 11 July 2012 11:53:51 Aish Raj Dahal wrote:<= br> >>> >> 1) Case One : When mimetype signal emitted by KIO::Tr= ansferJob is used
>>> >>
>>> >> In order to clarify more, let me take an example file=
>>> >>
>>> >> https://github.com/ar= dahal/kio-learner/blob/ard-dev/metalinkHttp/metalinkHtt
>>> >> p.cpp . The given file uses the mimetype signal (at l= ine 44) to get
>>> >> the
>>> >> headers as soon as the mimetype is emitted. The catch= is, since we do
>>> >> no want the redirected HTTP headers but instead want = the original HTTP
>>> >> headers, setRedirectionHandlingEnabled has been set t= o false. This
>>> >> program when run, does not emit the mimetype signal a= s all, and as a
>>> >> result the qDebugs at line 51 and 52 are never execut= ed . This
>>> >> behavior is seen not only for URLs which redirect (li= ke
>>> >> = http://www.example.com ) but also for URLs which have no redirection >>> >> (like http://www.google.com.np) .
>>> >
>>> > This is the part that makes no sense to me ;-)
>>> >
>>> > redirectionHandlingEnabled is a KIO::SimpleJob setting, t= he slave has
>>> > no idea
>>> > about that setting. If there's no redirection, then n= one of the code in
>>> > simplejob that checks for redirectionHandlingEnabled actu= ally runs.
>>> > So it can't possibly make any difference for a URL wi= thout redirection.
>>> >
>>> > I think your testcase is a bit wrong: http://www.google.com.np
>>> > redirects. I
>>> > can see it in the konqueror debug output:
>>> >
>>> > =C2=A0KonqRun::slotRedirection: KUrl("http://www.google.com.np"= ) ->
>>> > KUrl("http://www.google.com.np/")
>>> >
>>> > So if you want to test a URL that doesn't redirect, a= dd the trailing
>>> > slash
>>> > upfront.
>>> >
>>> > If you can confirm this, then we'll be down to: no ht= tp headers emitted
>>> > when a
>>> > redirection happens, which would be a kio_http issue. Daw= it?
>>> >
>>>
>>> Thanks a lot for the heads up about the test case :-)
>>>
>>> It does indeed run well as expected with
>>> KUrl("http://www.google.com.np/") as the test URL. However for thos= e
>>> URLs that do have redirection, no headers were emitted.
>>>
>>> Once again, thanks a lot.
>>
>>
>> I will try and clarify some things as much as I can:
>>
>> #1. Without some changes in kio_http, you will never see redirecti= on
>> headers received from HTTP server. This can probably be addressed = by
>> delaying the redirection request until after the HTTP headers have= been set.
>> However, the last time I attempted to fix this, it caused a regres= sion. See
>> bug#150904.
>>
>>
>> #2. When a redirection is requested, kio_http will never emit mime= Type
>> signal because it is not yet known. This should be very obvious be= cause a
>> redirection request is the server telling us the actual location o= f the
>> content we just requested. As such connecting to KIO's mimeTyp= e signal for
>> such circumstances is of no use.
>>
>> #3. If you do setRedirectionHandlingEnabled(false) in order to han= dle
>> redirections yourself, instead of KIO, then you have to connect to= KIO's
>> redirect signal and retrieve the redirect URL. IOW, you have to do= the same
>> thing you are doing in your "output" function from the s= lot connected to the
>> redirection signals.
>>
>> However, I suspect what you want to do is get any and all headers<= br> >> including those that have to do with redirection requests. If so, = then we
>> have to find a way for kio_http to set the HTTP headers before sen= ding the
>> redirection request without causing a regression.
>
>
> Actually I take back what I said in #1 and the last paragraph. I just = did
> some testing and you can indeed retrieve the redirection headers by si= mply
> connecting to KIO::TransferJob's redirection signal if you disable= the
> internal handling of redirections. All you have to do is check for the=
> "HTTP-Headers" meta-data in the slot connected you connected= to the
> redirection signal.
>
> Also, although there are two redirection signals, "redirection&qu= ot; and
> "permanentRedirection", you need only connect to the "r= edirection" unless
> you want to keep track of permanent redirections.
>


Thank you very much for looking into the issue.

Now, as you've suggested using KIO::TransferJob's redirection signa= l
to connect to a slot and then query for "HTTP-Headers" metadata ,= I've
faced an issue.
Before I get to the issue here is the pastebin of what I'd doing to
test it http://paste.kde.org/517220/42196913/ .
The issue is that although I am able to verify the redirection URL (if
the site was redirecting of course), querying the KIO::Job for
"HTTP-Headers" metadata keys left me with a QString("")= for result.
I've tried testing several URLs and had the same issue (which is quite<= br> strange). I've also tried by setting as well as unsetting the
PropagateHttpHeader metadeta keys, which again had no effect on the
result.

I hope you'll look into this matter and provide your valuable guidance.=

Thanks once again.

Regards,
Aish Raj Dahal

--f46d0446312c1d7be204c4ba8cf4-- --f46d0446312c1d7be804c4ba8cf6 Content-Type: text/x-chdr; charset=US-ASCII; name="metalinkHttp.h" Content-Disposition: attachment; filename="metalinkHttp.h" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h4lmaj800 LyoKQ29weXJpZ2h0IDIwMTIgIEFpc2ggUmFqIERhaGFsIDwgZGFoYWxhaXNocmFqIGF0IGdtYWls LmNvbSA+CgpUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yCm1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlIGFzCnB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mCnRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24p IGFueSBsYXRlciB2ZXJzaW9uLgoKVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBo b3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCmJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCk1FUkNIQU5UQUJJTElUWSBvciBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCllvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCmFsb25nIHdpdGggdGhpcyBwcm9n cmFtLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNlbnNlcy8+LgoKKi8KCiNp Zm5kZWYgc2hvd0h0dHBfSAojZGVmaW5lIHNob3dIdHRwX0gKCiNpbmNsdWRlIDxRdENvcmUvUU9i amVjdD4KI2luY2x1ZGUgPEtJTy9BY2Nlc3NNYW5hZ2VyPgojaW5jbHVkZSA8S0lPL0pvYj4KI2lu Y2x1ZGUgPEtJTy9TaW1wbGVKb2I+CiNpbmNsdWRlIDxLSU8vU2NoZWR1bGVyPgojaW5jbHVkZSA8 UXRDb3JlL1FFdmVudExvb3A+CgpjbGFzcyBtZXRhbGlua0h0dHAgOiBwdWJsaWMgUU9iamVjdAp7 CiAgICBRX09CSkVDVApwdWJsaWM6CiAgICBtZXRhbGlua0h0dHAoY29uc3QgS1VybCYpOwogICAg fm1ldGFsaW5rSHR0cCgpOwogICAgYm9vbCBpc01ldGFsaW5rSHR0cCgpOwoKcHJpdmF0ZSBzbG90 czoKICAgIHZvaWQgc2xvdEhlYWRlclJlc3VsdChLSm9iKiBram9iKTsKICAgIHZvaWQgY2hlY2tN ZXRhbGlua0h0dHAoKTsKICAgIHZvaWQgZGV0ZWN0TWltZShLSU86OkpvYiAqICBqb2IsIGNvbnN0 IFFTdHJpbmcgJiAgdHlwZSk7CiAgICB2b2lkIHNsb3RSZWRpcmVjdGlvbihLSU86OkpvYiosIGNv bnN0IEtVcmwmKTsKCnByaXZhdGU6CiAgICBLVXJsIG1fVXJsOwogICAgS1VybCBtX3JlZGlyZWN0 aW9uVXJsOwogICAgYm9vbCBtX01ldGFsaW5rSFNhdHVzOwogICAgUUV2ZW50TG9vcCBtX2xvb3A7 CiAgICBRTXVsdGlNYXA8UVN0cmluZywgUVN0cmluZz4gbV9oZWFkZXJJbmZvOwogICAgdm9pZCBw YXJzZUhlYWRlcnMoY29uc3QgUVN0cmluZyYpOwogICAgdm9pZCBzZXRNZXRhbGlua0hTYXR1cygp Owp9OwoKCgojZW5kaWYgLy8gc2hvd0h0dHBfSAo= --f46d0446312c1d7be804c4ba8cf6 Content-Type: text/x-c++src; charset=US-ASCII; name="metalinkHttp.cpp" Content-Disposition: attachment; filename="metalinkHttp.cpp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h4lmaj871 LyoKQ29weXJpZ2h0IDIwMTIgIEFpc2ggUmFqIERhaGFsIDwgZGFoYWxhaXNocmFqIGF0IGdtYWls LmNvbSA+CgpUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yCm1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlIGFzCnB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mCnRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24p IGFueSBsYXRlciB2ZXJzaW9uLgoKVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBo b3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCmJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCk1FUkNIQU5UQUJJTElUWSBvciBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KCllvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCmFsb25nIHdpdGggdGhpcyBwcm9n cmFtLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNlbnNlcy8+LgoKKi8KCiNp bmNsdWRlICJtZXRhbGlua0h0dHAuaCIKI2luY2x1ZGUgPGtkZWJ1Zy5oPgojaW5jbHVkZSA8UXRD b3JlL1FTdHJpbmc+CgptZXRhbGlua0h0dHA6Om1ldGFsaW5rSHR0cChjb25zdCBLVXJsJiBVcmwp CiAgICA6IG1fVXJsKFVybCksCiAgICAgIG1fTWV0YWxpbmtIU2F0dXMoZmFsc2UpCgp7CiAgICBj aGVja01ldGFsaW5rSHR0cCgpOwp9CgptZXRhbGlua0h0dHA6On5tZXRhbGlua0h0dHAoKQp7Cgp9 Cgp2b2lkIG1ldGFsaW5rSHR0cDo6Y2hlY2tNZXRhbGlua0h0dHAoKQp7CgogICAgS0lPOjpUcmFu c2ZlckpvYiAqam9iOwogICAgam9iID0gS0lPOjpnZXQobV9VcmwpOwogICAgam9iLT5hZGRNZXRh RGF0YSgiUHJvcGFnYXRlSHR0cEhlYWRlciIsICJ0cnVlIik7CiAgICBqb2ItPnNldFJlZGlyZWN0 aW9uSGFuZGxpbmdFbmFibGVkKGZhbHNlKTsKICAgIGNvbm5lY3Qoam9iLCBTSUdOQUwocmVzdWx0 KEtKb2IqKSksIHRoaXMsIFNMT1Qoc2xvdEhlYWRlclJlc3VsdChLSm9iKikpKTsgIC8vIEZpbmlz aGVkCiAgICBjb25uZWN0KGpvYiwgU0lHTkFMKHJlZGlyZWN0aW9uKEtJTzo6Sm9iKixLVXJsKSks IHRoaXMsIFNMT1Qoc2xvdFJlZGlyZWN0aW9uKEtJTzo6Sm9iKixLVXJsKSkpOyAvLyBSZWRpcmVj dGlvbgogICAgY29ubmVjdChqb2IsU0lHTkFMKG1pbWV0eXBlKEtJTzo6Sm9iKixRU3RyaW5nKSks dGhpcyxTTE9UKGRldGVjdE1pbWUoS0lPOjpKb2IqLFFTdHJpbmcpKSk7IC8vIE1pbWUgZGV0ZWN0 aW9uLgogICAgcURlYnVnKCkgPDwgIiBWZXJpZnlpbmcgTWV0YWxpbmsvSFRUUCBTdGF0dXMiIDsK ICAgIG1fbG9vcC5leGVjKCk7Cn0KCnZvaWQgbWV0YWxpbmtIdHRwOjpkZXRlY3RNaW1lKEtJTzo6 Sm9iKiBqb2IsIGNvbnN0IFFTdHJpbmcmIHR5cGUpCnsKICBxRGVidWcoKSA8PCB0eXBlIDsKICBx RGVidWcoKSA8PCAiTWltZSBUeXBlIHNpZ25hbCByZWNpZXZlZCIgOwogIG1fbG9vcC5leGl0KCk7 Cn0KCnZvaWQgbWV0YWxpbmtIdHRwOjpzbG90SGVhZGVyUmVzdWx0KEtKb2IqIGtqb2IpCnsKICAg IEtJTzo6Sm9iKiBqb2IgPSBxb2JqZWN0X2Nhc3Q8S0lPOjpKb2IqPihram9iKTsKICAgIGNvbnN0 IFFTdHJpbmcgaHR0cEhlYWRlcnMgPSBqb2IgPyBqb2ItPnF1ZXJ5TWV0YURhdGEoIkhUVFAtSGVh ZGVycyIpIDogUVN0cmluZygpOwogICAgcGFyc2VIZWFkZXJzKGh0dHBIZWFkZXJzKTsKICAgIHNl dE1ldGFsaW5rSFNhdHVzKCk7CgogICAgLy8gSGFuZGxlIHRoZSByZWRpcmVjdGlvbi4uLiAoQ29t bWVudCBvdXQgaWYgbm90IGRlc2lyZWQpCiAgICBpZiAobV9yZWRpcmVjdGlvblVybC5pc1ZhbGlk KCkpIHsgICAgICAgCiAgICAgICBtX1VybCA9IG1fcmVkaXJlY3Rpb25Vcmw7CiAgICAgICBtX3Jl ZGlyZWN0aW9uVXJsID0gS1VybCgpOwogICAgICAgY2hlY2tNZXRhbGlua0h0dHAoKTsKICAgIH0K fQoKdm9pZCBtZXRhbGlua0h0dHA6OnNsb3RSZWRpcmVjdGlvbihLSU86OkpvYiogam9iLCBjb25z dCBLVXJsIHVybCkKewogICAgUV9VTlVTRUQoam9iKQogICAgbV9yZWRpcmVjdGlvblVybCA9IHVy bDsgICAgCn0KCmJvb2wgbWV0YWxpbmtIdHRwOjppc01ldGFsaW5rSHR0cCgpCnsKICAgIGZvcmVh Y2goUVN0cmluZyBtYXB2YWwsIG1faGVhZGVySW5mbykgewogICAgICAgIHFEZWJ1ZygpIDw8IG1h cHZhbCA7CiAgICB9CgogICAgcmV0dXJuIG1fTWV0YWxpbmtIU2F0dXM7Cn0KCnZvaWQgbWV0YWxp bmtIdHRwOjpwYXJzZUhlYWRlcnMoY29uc3QgUVN0cmluZyAmaHR0cEhlYWRlcikKewogICAgUVN0 cmluZyB0cmltZWRIZWFkZXIgPSBodHRwSGVhZGVyLm1pZChodHRwSGVhZGVyLmluZGV4T2YoJ1xu JykgKyAxKS50cmltbWVkKCk7CgogICAgZm9yZWFjaChRU3RyaW5nIGxpbmUsIHRyaW1lZEhlYWRl ci5zcGxpdCgnXG4nKSkgewogICAgICAgIGludCBjb2xvbiA9IGxpbmUuaW5kZXhPZignOicpOwog ICAgICAgIFFTdHJpbmcgaGVhZGVyTmFtZSA9IGxpbmUubGVmdChjb2xvbikudHJpbW1lZCgpOwog ICAgICAgIFFTdHJpbmcgaGVhZGVyVmFsdWUgPSBsaW5lLm1pZChjb2xvbiArIDEpLnRyaW1tZWQo KTsKICAgICAgICBpbnQgbGVzc3RoYW5fcG9zID0gbGluZS5pbmRleE9mKCc8Jyk7CiAgICAgICAg aWYgKGxlc3N0aGFuX3BvcyA+PSAwKSB7CiAgICAgICAgICAgIGhlYWRlclZhbHVlID0gbGluZS5t aWQobGVzc3RoYW5fcG9zICsgMSkudHJpbW1lZCgpOwogICAgICAgIH0KICAgICAgICBtX2hlYWRl ckluZm8uaW5zZXJ0TXVsdGkoaGVhZGVyTmFtZSwgaGVhZGVyVmFsdWUpOwogICAgfQp9Cgp2b2lk IG1ldGFsaW5rSHR0cDo6c2V0TWV0YWxpbmtIU2F0dXMoKQp7CiAgICBib29sIGxpbmtTdGF0dXMs IGRpZ2VzdFN0YXR1czsKICAgIGxpbmtTdGF0dXMgPSBkaWdlc3RTdGF0dXMgPSBmYWxzZTsKICAg IGlmIChtX2hlYWRlckluZm8uY29udGFpbnMoImxpbmsiKSkgewogICAgICAgIFFMaXN0PFFTdHJp bmc+IGxpbmtWYWx1ZXMgPSBtX2hlYWRlckluZm8udmFsdWVzKCJsaW5rIik7CgogICAgICAgIGZv cmVhY2goUVN0cmluZyBsaW5rVmFsLCBsaW5rVmFsdWVzKSB7CiAgICAgICAgICAgIGlmIChsaW5r VmFsLmNvbnRhaW5zKCJyZWw9ZHVwbGljYXRlIikpIHsKICAgICAgICAgICAgICAgIGxpbmtTdGF0 dXMgPSB0cnVlOwogICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAgIH0KICAgICAgICB9 CiAgICB9CgogICAgaWYgKG1faGVhZGVySW5mby5jb250YWlucygiZGlnZXN0IikpIHsKICAgICAg ICBRTGlzdDxRU3RyaW5nPiBkaWdlc3RWYWx1ZXMgPSBtX2hlYWRlckluZm8udmFsdWVzKCJkaWdl c3QiKTsKCiAgICAgICAgZm9yZWFjaChRU3RyaW5nIGRpZ2VzdFZhbCwgZGlnZXN0VmFsdWVzKSB7 CiAgICAgICAgICAgIGlmIChkaWdlc3RWYWwuY29udGFpbnMoInNoYS0yNTYiLCBRdDo6Q2FzZUlu c2Vuc2l0aXZlKSkgewogICAgICAgICAgICAgICAgZGlnZXN0U3RhdHVzID0gdHJ1ZTsKICAgICAg ICAgICAgICAgIGJyZWFrOwogICAgICAgICAgICB9CiAgICAgICAgfQogICAgfQoKICAgIGlmICgo bGlua1N0YXR1cykgJiYgKGRpZ2VzdFN0YXR1cykpIHsKICAgICAgICBtX01ldGFsaW5rSFNhdHVz ID0gdHJ1ZTsKICAgIH0KCn0KCiNpbmNsdWRlICJtZXRhbGlua0h0dHAubW9jIgo= --f46d0446312c1d7be804c4ba8cf6--