💾 Archived View for gemi.dev › gemini-mailing-list › 000019.gmi captured on 2023-11-04 at 12:18:41. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hello Geminauts, I have a weird issue that came up when coding stuff on Asuka (my client) and maybe you can help. I?m adding support for opening whatever mime type a Gemini server is serving me. The logic I implemented so far is: - serve text/* in the client as usual - serve the other mime types by downloading content to a temporary file and opening it with xdg-open, open... In order to download the served content I first check the header as string, get its size as bytes, re-fetch the whole ?page? as bytes, reverse the bytes array, truncate it with the header length and finally reverse it again before writing it to a file. My issue is I have to add an offset of 5 bytes to the truncation for the files to be readable and I have no idea why. I tested this offset on several servers that are serving images, tarballs... and it looks consistent. Does it ring a bell by any chance? Or maybe I?m doing all of this completely wrong.
It was thus said that the Great Julien Blanchard once stated: > Hello Geminauts, > > I have a weird issue that came up when coding stuff on Asuka (my client) > and maybe you can help. I?m adding support for opening whatever mime type > a Gemini server is serving me. > > The logic I implemented so far is: > - serve text/* in the client as usual > - serve the other mime types by downloading content to a temporary file > and opening it with xdg-open, open... > > In order to download the served content I first check the header as > string, get its size as bytes, re-fetch the whole ?page? as bytes, reverse > the bytes array, truncate it with the header length and finally reverse it > again before writing it to a file. I'm not understanding what you are doing here. Here's how I would do this---read bytes until you have seen the CRLF [1]. That's the response from the server. I then would parse that line of data to get the response and MIME type. Then all I need to do is continue reading data from the server and write that data toa file. Then launch the external program. > My issue is I have to add an offset of 5 bytes to the truncation for the > files to be readable and I have no idea why. I tested this offset on > several servers that are serving images, tarballs... and it looks > consistent. > > Does it ring a bell by any chance? Or maybe I?m doing all of this > completely wrong. Not really. And whatever you are doing it seems overly complicated ... oh wait ... you aren't using Python 3 by any chance, are you? -spc (just a stab in the dark ... ) [1] ASCII character 13 and ASCII character 10
On 10/2/19 12:04 AM, Sean Conner wrote: > I'm not understanding what you are doing here. I wanted to remove the header part in the most convoluted way possible :D > Here's how I would do this---read bytes until you have seen the CRLF [1]. > That's the response from the server. I then would parse that line of data > to get the response and MIME type. Then all I need to do is continue > reading data from the server and write that data toa file. Then launch the > external program. OMG you're so right! I was trying to put a square peg in a round hole since I already had the content splitted has two strings (header/body) when I should have re-thought my parsing strategy the way you're describing directly at the bytes level. > Not really. And whatever you are doing it seems overly complicated ... oh > wait ... you aren't using Python 3 by any chance, are you? > > -spc (just a stab in the dark ... ) > > [1] ASCII character 13 and ASCII character 10 I'm using Rust but I'm curious what the issue could be with python 3? Anyway thanks a lot Sean! It helped a lot!
---
Previous Thread: TLS, TOFU and the Gemini security model
Next Thread: gusmobile, a Python library for Gemini requests