Espruino HTTP module appears to be HTTP 1.0

Can we confirm that the Espruino module is behaving as a HTTP/1.0 environment?
Are there any plans to enhance to later levels of the HTTP protocol? HTTP/1.1 has been a standard since 1997.

https://tools.ietf.org/html/rfc2068

To be conformant with http/1.1 quite a bit more code would be required. Chunked encoding being one, gzip being another, I believe. Is there any real gain to be had?

It all depends... the question is: where is espruino used and what use is reasonable. After all, resources are limited, and is the data going in an out. If not, may be the platform is not the right one.

It's just the HTTP/1.0 stuff that's needed at the moment.

What would HTTP/1.1 add that might be useful for users? IMO it's better to have a full implementation from pre-1997 than a half-implemented post-1997 one :)

I'm trying to imagine Espruino in a year or 2 years or 5 years. In projects that I am involved in ... in real-life ... we have fallen into the trap of "it works just fine now, why change anything" ... and the competition comes along and increments their functional base inch by inch ... a year later we look around and all of a sudden the customer base is saying "Why don't you do this ... and this ... and this ..." and by then its too late .. our competition has done all of that already.

We should assume that by this time next year or 2 years or 5 years ... the capabilities of the base MCUs will be dramatically better than we have today. If we don't plan to take advantage of those platforms, we will be caught short when the capability becomes actual.

This does bring up the concept though of strategic direction. Is Espruino focused exclusively at the low end MCU into the future? If it wants to remain at the low-end with the belief that the Linux eco system will prevail with its spectrum of development tools for higher end MCUs ... then yes ... maintenance mode of Espruino is probably sufficient.

the customer base is saying "Why don't you do this ... and this ... and this ..."

Yes, that sounds familiar ;)

The problem is that there's not enough manpower to just do what everyone wants. Espruino is only relatively popular today because I've ignored many (often good) requests or put them aside until they could be implemented with less effort or were actually blocking something/someone.

What I'm finding is, it's better for something to work 100% of the time than for it to have an extra feature that doesn't work correctly. Nobody notices when things just work, but they remember for a long time when they break :)

Is Espruino focused exclusively at the low end MCU into the future?

I think it has to be. It would be totally insane to try and re-implement the features of a full-blown OS like Linux. There are now people building Espruino boards into real things, and I don't want the firmware to get so big that it will no longer work on the existing boards. It's already getting to be a bit of a squeeze on the original Espruino.

The way I see it, if Espruino grows to bigger uCs, it becomes so big that keeping it bug-free becomes a real nightmare. It'll start to have requirements near uClinux, and then performance starts to look bad compared to native code or stripped-out desktop JS engines.

However if Espruino stays roughly where it is in terms of code size and instead gets smaller, lower power and cheaper with Moore's law, then it could really stand a chance of doing well.

My general priority list with Espruino is:

1. Stuff that's broken
   
2. Features that let you use Espruino for things you couldn't have used it for before
   
   

I'm not saying HTTP/1.1 is a bad idea. But we shouldn't do it just because 1.0 is 'old' - especially if it means that we then have to maintain a 1.0 version for the Espruino boards with less flash memory.

IMO things like IPv6 (and especially TLS) are significantly higher priority - they're not just 'nice to have', but enable Espruino's use in entirely new areas.

As far as I'm concerned, right now Espruino is running on something miles away from low end. Low end is 8k of flash, not 256k of flash :-P
And low end MCU's cover a huge range of capability - look at all that people do on Arduino with a processor at a quarter the clock speed with a sixteenth the flash and 1/32nd the ram...

I'm all for adding HTTP 1.1 - but only if there's a demand for it! The capabilities of general purpose computers, even back in the 90's, was far beyond what a microcontroller has, in terms of memory and program storage. Is it worth adding HTTP/1.1, in light of the extra flash space it would take up? What is it about HTTP/1.1 that is important for the microcontroller use case?

And yeah - TLS would be huge if we could get that working. Definitely higher priority than HTTP/1.1, unless that has superpowers I don't know. IPv6, maybe not so much yet (sometimes we test our product with it at work. Never had to use it in real life though)