[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Using KIO to retrive HTTP Headers [GSoC student help request]
From:       Dawit A <adawit () kde ! org>
Date:       2012-07-08 14:06:19
Message-ID: CALa28R4UW97BFucj0+1TL9iHs4867jaaiEcv+t6WSH4fN-fCGw () mail ! gmail ! com
[Download RAW message or body]

On Sun, Jul 8, 2012 at 4:29 AM, David Faure <faure@kde.org> wrote:

> On Thursday 28 June 2012 06:13:15 Aish Raj Dahal wrote:
> > The issue is that KIO attempts to download the entire file before
> > being able to query for its HTTP header responses. This behavior may
> > be taken lightly for smaller files, however for larger files
> > downloading an entire file, just to get the HTTP header response
> > associated with it seems to be impractical.
>
> As Albert said, the headers are sent as soon as they are received, and the
> mimetype signal is emitted before the contents of the file, this is by
> contract
> for KIO::get(). This is how we can put the job on hold while launching the
> proper application for that url, and the app then resumes the download in
> order to get the file contents.
>
>
> Alternatively you could use KIO::mimetype which performs an HTTP HEAD
> request
> on the given URL, but we had the experience (many years ago) that some
> webservers didn't reply correctly to HEAD requests.
>

The other alternative (actually a hack) you have is to connect to the KIO's
mimeType signal and put the ioslave on hold as outlined in KIO::get's
documentation. That should allow you to retrieve the header before
downloading the file. You can then resume the download by issuing a second
get request.

Dawit A.

[Attachment #3 (text/html)]

<br><br><div class="gmail_quote">On Sun, Jul 8, 2012 at 4:29 AM, David Faure <span \
dir="ltr">&lt;<a href="mailto:faure@kde.org" \
target="_blank">faure@kde.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

<div class="im">On Thursday 28 June 2012 06:13:15 Aish Raj Dahal wrote:<br>
&gt; The issue is that KIO attempts to download the entire file before<br>
&gt; being able to query for its HTTP header responses. This behavior may<br>
&gt; be taken lightly for smaller files, however for larger files<br>
&gt; downloading an entire file, just to get the HTTP header response<br>
&gt; associated with it seems to be impractical.<br>
<br>
</div>As Albert said, the headers are sent as soon as they are received, and the<br>
mimetype signal is emitted before the contents of the file, this is by contract<br>
for KIO::get(). This is how we can put the job on hold while launching the<br>
proper application for that url, and the app then resumes the download in<br>
order to get the file contents.<br>
<br>
<br>
Alternatively you could use KIO::mimetype which performs an HTTP HEAD request<br>
on the given URL, but we had the experience (many years ago) that some<br>
webservers didn&#39;t reply correctly to HEAD \
requests.<br></blockquote><div><br></div><div>The other alternative (actually a hack) \
you have is to connect to the KIO&#39;s mimeType signal and put the ioslave on hold \
as outlined in KIO::get&#39;s documentation. That should allow you to retrieve the \
header before downloading the file. You can then resume the download by issuing a \
second get request.</div>

<div><br></div><div>Dawit A.</div></div>



[prev in list] [next in list] [prev in thread] [next in thread]