Re: [PATCH] shrink last_char_is function even more

2020-07-09 Thread Martin Lewis
Please note that my original patch is still smaller: http://lists.busybox.net/pipermail/busybox/2020-June/088026.html I'm not sure whether it's faster, it would be interesting to compare them. On Tue, 7 Jul 2020 at 14:17, Tito wrote: > Hi, > attached you will find a patch that shrinks libbb's

Re: [PATCH 3/4] lsscsi: code shrink and refactor

2020-07-09 Thread Martin Lewis
Here's the struct as specified in the kernel: /* From /drivers/scsi/scsi_sysfs.c in the kernel: * sdev_rd_attr (type, "%d\n"); * sdev_rd_attr (vendor, "%.8s\n"); * sdev_rd_attr (model, "%.16s\n"); * sdev_rd_attr (rev, "%.4s\n"); */ As you can see, type is always printed with %d which should

[PATCH] domain_codec: optimize dname_dec and convert_dname

2020-07-09 Thread Martin Lewis
dname_dec: now iterates over the packet only once. convert_dname: remove redundant checks and code shrink. While testing I've noticed that some of the tests didn't compile properly, so I fixed them. function old new delta dname_dec

Re: [PATCH 3/4] lsscsi: code shrink and refactor

2020-07-09 Thread Markus Gothe
Jon Postel formulated the robustness principle decades ago. Still today it is a good advice to "be liberal in what you accept and strict in what you send".Micro-optimizations as this will cause more problems when things actually do fail than they are worth in the long run.I could buy the

Re: [PATCH] shrink last_char_is function even more

2020-07-09 Thread Tito
On 7/9/20 9:56 PM, Martin Lewis wrote: > Please note that my original patch is still smaller: > http://lists.busybox.net/pipermail/busybox/2020-June/088026.html Hi, yes I know. This is smaller than what is in git now. I understood that Denis rejected your patch: "This scans the string twice,

[PATCH 0/4] HTTPD: Add caching

2020-07-09 Thread Sergey Ponomarev
HTTP caching significantly decreases load and becomes especially important for embedded systems. HTTPD already returns Last-Modified header which then browser is sends back to server via If-Modified-Since. Server must compare these two dates and return 304 Not Modified without payload. But the

[PATCH 3/4] httpd: Support caching via 'ETag:' header

2020-07-09 Thread Sergey Ponomarev
If server returned ETag in response then next time client (browser) will add it to request into If-None-Match header. Then httpd will check if file wasn't modified and if not return 304 Not Modified status code. The ETag value is itself the last modification date in unix epoch. Signed-off-by:

[PATCH 4/4] httpd: update to HTTP/1.1

2020-07-09 Thread Sergey Ponomarev
The ETag header was introduced in HTTP v1.1 in 1999 year. Chrome not send the If-None-Match header if server uses old HTTP/1.0 protocol. Signed-off-by: Sergey Ponomarev --- networking/httpd.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[PATCH 2/4] httpd: send ETag header instead of Last-Modified

2020-07-09 Thread Sergey Ponomarev
The Last-Modified header is used for caching. The client (browser) will send back the received date to server via If-Modified-Since request header. But both headers MUST be an RFC 1123 formatted string. And the formatting consumes resources on request parsing and response generation. Instead the

[PATCH 1/4] httpd: do not send useless Date header

2020-07-09 Thread Sergey Ponomarev
In RFC 2616 section 14.18 said that sever MUST send Date header https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 But in fact the header is often ignored and makes sense only for caching by age `Cache-Control: max-age=21600` when server clock is wrong. But BusyBox have support of

Re: [PATCH 3/4] lsscsi: code shrink and refactor

2020-07-09 Thread Michael Conrad
On 7/9/2020 3:16 PM, Markus Gothe wrote: Jon Postel formulated the robustness principle decades ago. Still today it is a good advice to "be liberal in what you accept and strict in what you send". Counterexample: Internet Explorer It allowed so much garbage to render correctly that other

Re: [PATCH 3/4] lsscsi: code shrink and refactor

2020-07-09 Thread Markus Gothe
The robustness principle is about handling faulty behaviours and not about implementing not-defined/non-standard things just to be compatible with other vendors. However if another vendor uses something non/not-defined one should take care of the corner-case and not let the running code result

Re: [PATCH 3/4] lsscsi: code shrink and refactor

2020-07-09 Thread Jody Bruchon
Allowing erroneous pages to render is not inherently bad, especially with standards that can change in the future. Look at earlier HTML (< 4) vs XHTML. If a page is written in XHTML and is read by a browser that doesn't understand XHTML, the browser still attempting to render it by ignoring any