[ih] Internet analyses (Was Re: IPv8...)

[Larry Masinter]

((sitting as a draft in my mailbox for too long))

Adding forms and file upload didn't cause significant complexity to the
network protocol part of the web or additional server load.

Although update and user editing were part of the early vision of the web,
most of the complexity fell on the user interface.

There isn't a <POST/> HTML element. You could do a POST (HTTP method) via
HTTP and build a UI to submit one via <FORM/>.  And RFC 1967 was (I think)
the first to add the "file upload" capability
    https://datatracker.ietf.org/doc/html/rfc1867

but forms and file upload  wasn't a major performance issue (in the same
way that IMG did) because it still would be one network connection per user
mouse-click.

Web complexity grew because the functionality was split between HTML and
HTTP with separate workflows for producing and deploying each.

That HTTP proceeded to build what it needed on top of TCP rather than, say,
building on expanding XNS Courier remote procedure call) might be thought
of as another cause -- the "plumbers" who were in charge of network
infrastructure didn't give the HTTP use cases seriously (until HTTP/3.0?)


--
https://LarryMasinter.net  https://interlisp.org


On Thu, Apr 30, 2026 at 7:06 PM Brian E Carpenter <
brian.e.carpenter at gmail.com> wrote:

> Larry, I agree that <IMG/> made a big difference but surely it was <POST/>
> that really made HTML/HTTP different?
>
> Regards/Ngā mihi
>     Brian
>
> On 29-Apr-26 09:59, Larry Masinter via Internet-history wrote:
> >> Gopher was (is?) a similar cautionary tale. It was a good design and
> >> although it was a lot less flexible than the web, it was also a lot
> >> easier to implement and loaded the servers less.
> >
> > http 0.9 was essentially gopher: open a connection, GET the document in
> one
> > exchange, close the connection. One transaction per document/directory
> > list.  The complexity came from using multiple connections for a single
> > document with many embedded images rather than portable compound document
> > formats, moving the format complexity into the protocol.
> >
> > As. a side note, adding  M. McCahill, University of Minnesota, (RFC 1436)
> > as an editor of RFC 1738 (URL) helped show the gopher community how to
> > preserve their investment in gopher servers while migrating to the web.
>