[Grub-dev] do we even really need a native client

Balinny balinny at gmail.com
Thu Jan 10 13:33:24 UTC 2008


jer wrote:
>> However, as i'm not a fluent speaker of Perl, i went to create a C
>> version :-)
>>     
> I was tempted to do that too, but it'd be even more shaky than the  
> perl version given the time :)
>   
:-)
>   
>> I found a number of doubts:
>> *At the perl version you do print $arc "http://$host$path $ip
>> 19691231175959 $ctype ",length($body),"\n$body"; so the end of  
>> previous
>> page body touches the start of next chunk, but from
>> http://www.archive.org/web/researcher/ArcFileFormat.php a \n would be
>> required in front of http://
>>     
>
> Perhaps I mis-read it!
>
> doc == <nl><URL-record><nl><network_doc>
>
> URL-record-v1 == <url><sp>
> <ip-address><sp>
> <archive-date><sp>
> <content-type><sp>
> <length><nl>
>
>
> So, there should be two newlines? "\n\n$body" ?
>   
It's the <nl> at the beginning of doc the one not being honoured.

>> *What to do with Transfer-Encoding: chunked?
>> **Remove the header + decode body
>> **Keep header + decode body
>> **Keep Header + keep body
>> (perl renames header to Client-Transfer-Encoding and decodes body)
>> I vote for Keep header + decode body, so that allows the client to do
>> things like fetching the content compressed but preserve original data
>> for the server.
>>     
>
> Easier, rfc 2616: "A server MUST NOT send transfer-codings to an HTTP/ 
> 1.0 client" and we're doing 1.0 requests.
>   
Right. But a client could wish to speak HTTP/1.1 There's still that 
problem  with the compression.


What about the user-agent vs agent issue?


More information about the Grub-dev mailing list