From: telephil9@gmail.com
To: ori@eigenstate.org, knusbaum@sdf.org, 9front@9front.org,
kokamoto@hera.eonet.ne.jp
Subject: Re: [9front] adding javascript enable to netsurf
Date: Fri, 20 Mar 2020 18:12:41 +0100 [thread overview]
Message-ID: <77D9629A24752EF2B79C31DC37C2C76C@gmail.com> (raw)
In-Reply-To: <2E9D0BC175C6CB97ED70074A091C37A7@eigenstate.org>
On Fri Mar 20 17:16:38 CET 2020, ori@eigenstate.org wrote:
> > I think the error is due to a limitation of the webfs fetcher. Currently, the fetcher hangs on
> > to webfs handles until they're freed by netsurf, even after the data is
> > read, because after they're closed things like headers are unavailable.
> > This means tha webfs handles can be exhausted, at which point netsurf
> > starts to run into that error.
> >
> > This can definitely be improved in the webfs fetcher, but maybe the
> > relatively low webfs handle limit could also be raised.
> >
>
> Are they ever released, or are they effectively leaked?
>
> Also, searching on Google just.. doesn't work. It seems like we get
> a bogus URL.
>
I tracked this one down to iconv not being implemented (see posix/src/iconv.c).
For the bogus URL, the reason is that when the form is submitted, its fields are encoded (form_encode_item() in netsurf/content/handlers/html/form.c) using iconv which returns null each time (hence the many =&=&=&=).
Proper fix would be to implement the iconv() function, easy cheat is to return the unmodified item in the form_encode_item() function.
next prev parent reply other threads:[~2020-03-20 17:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 5:49 kokamoto
2020-03-20 16:10 ` Kyle Nusbaum
2020-03-20 16:15 ` ori
2020-03-20 17:12 ` telephil9 [this message]
2020-03-20 17:40 ` Jens Staal
2020-03-20 18:54 ` jamos
2020-03-21 5:00 ` Jens Staal
2020-03-21 12:24 ` Ethan Gardener
2020-03-20 22:07 ` Kyle Nusbaum
-- strict thread matches above, loose matches on Subject: below --
2020-04-14 5:04 kokamoto
2020-04-14 21:53 ` Kyle Nusbaum
2020-04-15 20:05 ` jamos
2020-04-15 20:24 ` ori
2020-04-18 1:09 ` Kyle Nusbaum
2020-04-18 1:19 ` ori
2020-04-18 17:11 ` Eli Cohen
2020-04-18 17:15 ` telephil9
2020-04-18 17:17 ` ori
2020-04-13 23:46 kokamoto
2020-04-07 4:25 kokamoto
2020-04-06 5:48 kokamoto
2020-04-13 12:44 ` jamos
2020-04-05 4:52 kokamoto
2020-04-05 4:41 kokamoto
2020-03-22 23:47 kokamoto
2020-03-22 2:19 kokamoto
2020-03-21 3:24 kokamoto
2020-03-22 20:27 ` jamos
2020-03-22 20:54 ` ori
2020-03-22 20:54 ` ori
2020-03-17 11:16 kokamoto
2020-03-17 17:42 ` jamos
2020-03-15 9:42 kokamoto
2020-03-15 11:06 ` Steve Simon
2020-03-15 11:38 ` Jens Staal
2020-03-15 13:50 ` jamos
2020-03-14 1:49 kokamoto
2020-03-14 2:09 ` ori
2020-03-14 1:19 kokamoto
2020-03-14 1:34 ` ori
2020-03-13 4:33 kokamoto
2020-03-13 4:58 ` ori
2020-03-12 5:28 kokamoto
2020-03-12 2:20 kokamoto
2020-03-12 2:43 ` ori
2020-03-11 23:59 kokamoto
2020-03-11 10:27 kokamoto
2020-03-11 6:36 kokamoto
2020-03-11 9:29 ` [9front] " jamos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77D9629A24752EF2B79C31DC37C2C76C@gmail.com \
--to=telephil9@gmail.com \
--cc=9front@9front.org \
--cc=knusbaum@sdf.org \
--cc=kokamoto@hera.eonet.ne.jp \
--cc=ori@eigenstate.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).