Microsoft: "HTTP aan het einde van zijn levensloop"

Nu dat men langzamerhand bezig is met het vervangen van IPv4 naar versie 6 om zo meer internetadressen te creëeren ziet het er ook naar uit dat HTTP zijn limieten aan het bereiken is. Don Box, werkzaam voor het Microsoft .NET Developer Platform, zei op de European DevWeek in Londen dat het HyperText Transfer Protocol uiteindelijk vervangen zal worden, maar dat het nog niet duidelijk is door wat. Een limitatie van HTTP is bijvoorbeeld dat er maar één kant van de lijn een uitwisseling via HTTP kan starten, de andere kant is slechts passief. Hieronder een gedeelte uit het artikel:

"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."

[...]There is work going on to address the shortcomings of HTTP, said Box. Several working groups are working on the problem at the W3C, the organisation responsible for Web standards. And even though Microsoft is working on the problem too, Box did say that Microsoft is unlikely to succeed alone.

Met dank aan Verwijderd voor de tip.

Reacties (107)

[ColdRain]

Het is net een van de vele voordelen van HTTP dat het aan een kant passief is. Stel je voor dat internet echt zou werken als een aktieve client-server omgeving ... ocharme de bandbreedte.
MS zal wel weer iets in de schuif hebben liggen zeker? Iets dat ze zonodig overal wel zullen opdringen. Benieuwd wat W3 van dit alles vindt ..

[EfBe]

Denk eens na voordat je je kaken van elkaar trekt.

We praten hier niet over 3-page websites met louter vakantiekiekjes en zeurverhalen vol spelfouten waar 3 halve garen per maand per ongeluk op verzeilen.

We praten hier over webapplicaties met interfaces in de vorm van webpages. De user zit dus niet in een request-response handshake systeem, maar werkt in een session met de applicatie. Nu is dat dus niet mogelijk, je bent altijd aangewezen op truuks zoals cookies etc, maar wat je wilt is een 2 way session waarbij de user niet met: hi-request-response-toedeledokie werkt maar met: hi-connect-[doe allerlei acties op allerlei pages]-disconnect.

Met HTTP op dit moment kan dat niet. Wat mensen hier echter weer niet begrijpen is: HTTP kan gewoon naast een ander protocol blijven bestaan. Ipv dat je dan [url="http://blablabla"]HTTP://blablabla[/url] intikt, tik je in NHTTP://blablabla (of iets dergelijks). dat bv verbinding maakt met poort 81 ipv 80.

HTTP is nooit bedoeld voor webapplicaties met sessions waarin users over meerder pagina's verdeelde acties uitvoeren, maar de passieve 'u vraagt, wij draaien' situatie. Als tijden veranderen, mag je best protocollen aanpassen of vervangen. Vasthouden aan oude troep dat niet meer werkt, DAT is veel erger.

[Marcel Loesberg]

Denk eens na voordat je je kaken van elkaar trekt.

Het mag wel iets vriendelijker.

De user zit dus niet in een request-response handshake systeem, maar werkt in een session met de applicatie. Nu is dat dus niet mogelijk, je bent altijd aangewezen op truuks zoals cookies etc

Dat kan dus wel. Ik heb zelf net een applicatie gebouwd waarbij er zonder cookies sprake is van een sessie.
Hiertoe maak ik gebruik van de Apache::Session module die je op CPAN kan vinden (http://www.cpan.org).

edit:
Dit kan ook door middel van "persitent sessions", een speurtocht via google leerde mij dat Apache hiertoe prima in staat is. Maar hoe het precies werkt..., weet iemand dat?

[Crazy D]

Ja en waar dacht je dat sessie-gegevens opgeslagen worden? Je zal aan de client-kant toch altijd een indicator moeten hebben voor welke user bij welke sessie hoort.
Sessies zijn leuk, tuurlijk, en zijn ook nuttig. Maar niet voor een client-server systeem zoals sommige webapplicaties eigenlijk nodig hebben (en dan heb ik het niet over een forum maar over echte apps..).
Jammer dat ie (nog?) niet zegt aan wat voor oplossing MS dan zit te denken.

[edit]typo

[aphx]

Dat kan dus wel. Ik heb zelf net een applicatie gebouwd waarbij er zonder cookies sprake is van een sessie.

Dat is een truuk. Je kunt gebruik maken van "url-rewriting", je voegt aan elke link een nieuw uniek nummer toe, iedere keer als er een pagina opgevraagd wordt.
Maar dan praat je nog steeds over een session die je aan de server-kant moet bijhouden.

Je zal aan de client-kant toch altijd een indicator moeten hebben voor welke user bij welke sessie hoort.

Die indicator zit dan in de link.

Volgens mij wordt die truuk ook bij veel mailings toegepast. Klik je op de link (bijv. www.pagina.nl/~1231352sdfsdt432tsdf en dan weet de server ~1231352sdfsdt432tsdf dat is [e-mail])

[Crazy D]

Ja ok kan ook in de URL. Dat is ongeveer net zo handig als via post-formpjes iemand door je site laten navigeren (imho dan). Per saldo is het een soort work-around om toch een client-server effect na te bootsen.

[Verwijderd]

We hebben een Ie, we hebben een Pee, we hebben een IP! Maar sowieso, dat hoeft zelfs nog niet... gewoon hidden fields gebruiken in je forms, is niet zo netjes ok, maar er hoeft niets "opgeslagen" te worden client-side.

[Unipuma]

Wat ik me afvraag...
het gaat hier voornamelijk over het gebruik van HTTP door webservices. Webservices zijn geen webpagina's die je met je browser bekijkt, maar stukken programma die door andere progamma's kunnen worden aangeroepen. Wat heeft dit uberhaupt te maken met HTTP? Waarom moet dit over poort 80? Toen HTML pagina's werden geintroduceerd werd dit toch ook niet op poort 21 gedaan 'omdat FTP servers al bestonden'?
IPV te zeggen dat HTTP verouderd is zou men eens moeten denken of men niet een nieuw en eigen protocol moet maken voor deze compleet andere functionaliteit.
Het is wel begrijpelijk dat men het zo probeert, immers, bijna elk bedrijf heeft tegenwoordig een firewall, en met poort 80 kun je er mooi doorheen glippen, maar dat is niet de bedoeling van die firewall.
Daarnaast, Microsoft zelf heeft aangegeven dat alles van de directe connectie naar losely coupled gaat (zelfs bij gebruik van databases, dat is wat ADO.NET moet gaan doen), wat inhoudt dat je een request verstuurt en dan afwacht tot je een reactie krijgt, maar ondertussen gewoon doorgaat. Je verstuurt dus een bericht, maar je houdt de connectie niet vast tot je antwoord hebt gekregen. Dat is dus een passief gebruik van je protocol.

[Verwijderd]

Daarnaast, Microsoft zelf heeft aangegeven dat alles van de directe connectie naar losely coupled gaat (zelfs bij gebruik van databases, dat is wat ADO.NET moet gaan doen), wat inhoudt dat je een request verstuurt en dan afwacht tot je een reactie krijgt, maar ondertussen gewoon doorgaat. Je verstuurt dus een bericht, maar je houdt de connectie niet vast tot je antwoord hebt gekregen. Dat is dus een passief gebruik van je protocol.

Dat is perfect realiseerbaar met bestaande protocollen, zoals ICQ, jabber, ..., meer zelfs, de beste oplossing lijkt me zelfs SMTP!

[Verwijderd]

Met HTTP op dit moment kan dat niet. Wat mensen hier echter weer niet begrijpen is: HTTP kan gewoon naast een ander protocol blijven bestaan. Ipv dat je dan [url="http://blablabla"]HTTP://blablabla[/url] intikt, tik je in NHTTP://blablabla (of iets dergelijks). dat bv verbinding maakt met poort 81 ipv 80.

En dan moet iedere opa, oma, buurman en -vrouw, enz enz enz die voor een tientje per uur internetleskrijgen, dat ze nu HTTP:// of NHTTP:// (of whatever://) in moeten typen? Ik denk dat dat zeker niet gaat lukken, daar moet iets anders voor komen...

Misschien als je www.bladiebla.com en xww.bladiebla.com (ofzooo) zou hebben als scheiding, dat het minder problemen geeft, maar het lijkt me lastig...

[ycode]

Dat lijkt me niet zo'n probleem. Als leek kun je best naar www.deshop.nl gaan dan naar nhttp://dit.is.de.shop.org gaan ofzo...

Dus da's niet onoverkomelijk...

[Diederik]

[/offtopic] kan het beoordelings systeem niet uitgebreid worden met -1 onzin en -1 heeft artikel niet gelezen
[offtopic]

[Beaves]

Er wordt nergens gezegd dat ze het support voor HTTP willen stopzetten, alleen dat er "iets" nieuws moet komen in hun opinie omdat de beperkingen van HTTP langzamerhand steeds groter worden.

HTTP zal gewoon gesupport blijven worden, want anders werkt straks internet ineens niet meer omdat het zeer veel tijd en moeite kost om een server om te zetten. De browsers zullen straks gewoon nog een protocol erbij ondersteunen, net zoals ze nu naast HTTP en FTP ook nog steeds oude protocollen zoals Gopher ondersteunen.

[GREENSKiN]

N00b's zoals jij ze noemt zullen nooit in contact komen met HTTP, je bedoeld vast HTML.
Ik zie ook geen reden waarom bestaande site's (lees: bestanden) niet via een ander protocol verstuurd kunnen worden.

[Sardia]

HTTP is het transport protocol voor html. Waarschijnlijk vindt MS dan ook dat we naar nieuwere technieken toemoeten, bv C# of ASP of andere microsoft toolie.

[Verwijderd]

En hoe gaan programmeer/script-talen voor dit transport zorgen? Als je beseft dat HTTP een transport protocol is begrijp ik niet welk punt je wil maken door niet-protocollen te vermelden als alternatieve technologie om naar over te schakelen.

[Slush]

Sardia: Dat lijkt me niet waar, aangezien het hele .NET framework er juist op gebaseerd is dat het niet meer uitmaakt welke programmeer-/script taal je gebruikt...!

[Verwijderd]

en ASP of C# poepen geen HTML uit wil je zeggen?

[Verwijderd]

ASP en C# zijn programmeertalen, geen netwerkprotocollen

[Verwijderd]

scriptingtalen, geen programmeertalen

[raptorix]

Asp is geen taal maar een technologie waar een hele reeks van talen voor gebruikt kunnen worden.

[YellowCube]

Volgens mij zal dat "in 1 keer veranderen" wel meevallen...Ik denk dat als je over 10 jaar terug kijkt op het grote plaatje, veel veranderingen in zekere zin "onopgemerkt" zijn gegaan

[Verwijderd]

jah neem nou flash, is fully intergrated, maar 5 jaar geleden had er echt niemand van gehoord, en wie heeft nou ecxht die verandering heel sterk gevoeld(het leek eerst zo op animated gif, dus...)

[Saus]

ik vind wel dat ze het moeten blijven ondersteunen, er zijn zat n00bs die geen zin hebben om hun website te veranderen omdat ze nu daar in één keer mee komen

Mja voordat heel HTTP weggevaagd > is, zijn we allemaal alweer een stukje ouder hoor. Zo'n vaart zal het denk ik niet lopen

[Pwigle]

Dat zeiden ze ooit ook van de diskette..
Ik denk dat het niet te doen is om alle bestaande html pagina's om te toveren tot een nieuwe standaard.

Er zal dus wel een backwards compabiliteits zijn tussen "opvolger html" <---> "huidge html"

Maar http zoals die nu is zal waarschijnlijk nooit verdwijnen

[Arno]

Maar http zoals die nu is zal waarschijnlijk nooit verdwijnen

Lijkt mij ook niet. Bepaalde dingen (zoals routers en andere http enabled devices) zijn niet zo eenvoudig aan te passen aan een nieuwe http standaard als bijvoorbeeld een webserver

[GREENSKiN]

HTTP is iets anders dan HTML, het is het protocol wat webservers gebruiken waarover o.a. HTML bestanden verstuurd worden.

[Verwijderd]

Niet html verdwijnt, maar http, het protocol. Dus dat je GET of POST doet om een pagina te krijgen, en wat je headers zijn, en of je de verbinding open houdt... Het gaat hier om de context van .NET, en dat is dus SOAP. In je http request zit dan een request in XML, en het antwoord is ook weer in XML. Daar komt geen html aan te pas.
In http/1.1 zitten ook al nieuwe dingen die in http/1.0 niet zaten, bv. keep-alive: je kan de verbinding open houden na een request.
Misschien zou dit http/1.2 of zelfs http/2.0 kunnen worden...

[Renegade]

Er staat zelfs niet dat HTTP zal verdwijnen, er staat alleen dat er iets nieuws nodig is. Zelf denk ik dat HTTP gewoon zal blijven bestaan, maar dat het gebruik ervan langzaam maar zeker zal vervagen, net zoals het eigenlijk ook met gopher is gebeurd.

[Verwijderd]

Daar zit wat in, er word toch ook nog steeds gebruik gemaakt van IBM compatible computers (640KB!!!) en Microsoft Windows is voor de home/textverwerker editions altijd (DOS!!!) compatible geweest.
Backwards compatible vernieuwingen worden altijd veel meer gebruikt dan volledig nieuwe techologien (als je begrijpt wat ik bedoel, ze hebben echt wel geprobeerd om van die 640 Kb af te komen.)

[Bally]

Microsoft kennende zal dat wel niet gebeuren. Ook oude c++ code en vb code moeten zo goed als opnieuw worden geschreven in het .net!

[blaatenator]

MS kennende Ken jij MS dan? Als er een fabricant is die backwards compatible blijft met hun producten is het MS wel.
Of had je nog wat concrete voorbeelden?

'k kan hier nog steeds NC oid op XP draaien. Maar ja, je hebt zeker nog nooit gehoord van WOW.
Programma's die DOS4gw of een vergelijkbare techniek gebruikten is een iets ander verhaal, en er is een goede reden voor dat die moeilijk aan de praat te krijgen zijn onder een geavanceerd OS als NT of XP.

Vind het beschamend om te zeggen maar door dit soort reacties, en die rechtzaken die nergens over gaan, begin ik soms gewoon sympathie te krijgen voor MS

Als je het hebt over het feit dat MS met Visual C++ een iets andere implementatie van C++ heeft gebruikt, waardoor die taal eigenlijk niet meer ANSI compatible is (same with java), dan geeft ik je gelijk, en ook denk ik niet dat MS die producten op deze manier heeft uitgebracht omdat hun programmeurs onkundig zijn vwd betreft.

[deadinspace]

Als er een fabricant is die backwards compatible blijft met hun producten is het MS wel.

Heb jij wel eens geprobeerd Access 2000 bestanden te openen in Access 97? Of Office XP docs in Office 97?
ALs er één fabrikant is die niet backwards compatible is, dan is het MS wel.

En ja, dit is offtopic, maar dit moest even gezegd worden.

[The End]

Je kan wel Access 97 documenten openen in Access 2000. Dat is backwards compatible.
Access 2000 documenten openen in Access 97 is forwards compatible (of zo iets).
Hoe wil jij dan ooit nieuwe features maken in een product als de files identiek moeten blijven????

[Dennis van der Stelt]

ALs er één fabrikant is die niet backwards compatible is, dan is het MS wel.

Echt onzin!
Eindelijk heeft Microsoft de stap genomen om .NET te maken wat inderdaad niet backwards compatible is. Terecht zeg, we kwamen met z'n allen tegen het limiet van alle programmeer talen en zeker ASP was toe aan vernieuwing. ASP.NET is waanzinnig!!!

Verder is Microsoft overal backwards compatible. Van die Word documenten van 97 naar 2000 kan kloppen, want ook dáár heeft Microsoft hele grote veranderingen gemaakt in de bestandslayout. Het hele principe van Word documenten is toen anders geworden.

Maar als Microsoft niet backwards-compatible meer zou zijn, zou dat zo'n slag betekenen voor Microsoft, dat ze misschien zelfs wel failliet gaan. En daar zijn ze zich maar al te goed van bewust, dat dát kan gebeuren.

[Verwijderd]

Je kan wel Access 97 documenten openen in Access 2000.

Wel jammer dat je Word97 documenten niet altijd zonder problemen kan openen in Word2000 (ik spreek uit ervaring).

En dat VB6-programma's niet werken onder VB.NET zonder een hele hoop wijzigingen.

Hoe wil jij dan ooit nieuwe features maken in een product als de files identiek moeten blijven????

De files moeten niet identiek blijven als het bestandsformaat rekening houdt met uitbreidingen in de toekomst. Dat lukt al jaren met SGML, HTML, GIF, PostScript, &c.

[Adion]

Trouwens, oude C++ code blijft werken in .net hoor, alleen visual basic is volledig nieuw alsook c#.

http lijkt mij voor de huidige toepassingen goed genoeg, maar het zou inderdaad wel handig zijn als er een iets meer gestandardizeerd protocol komt voor andere toepassingen ook, zoals streaming media enzo.
Het is zeker niet slecht voor de kwaliteit en de mogelijkheden als hier een goede standaard voor komt.
Om nu te zeggen dat HTTP volledig aan zijn einde is vind ik echter ook wat ver gaan.

[Slush]

Dat HOEFT niet. Waarom zou je bewezen programmatuur aanpassen? Dat heeft MS zich ook bedacht en heeft in hun implementatie van .NET er rekening mee gehouden dat oude .dll's en com-objecten en wat dies meer zij gewoon gebruikt kunnen blijven worden...!

off-topic?

[Verwijderd]

Als ik het zo lees is dat juist wel de bedoeling

[Verwijderd]

Zit wat in. HTTP is al weer aardig op leeftijd en de technologie staat niet stil. Die Don Box is ook geen dommerdje dus hij zal wel wat plannetjes hebben liggen, ik zie in het artikel echter alleen wat hints maar geen daadwerkelijke voorstellen, is daar al informatie over?

[kareltje21]

Voor het doel dat HTTP dient, het versturen van informatie die de andere partij vraagt is het nog prima geschikt. Hiervoor is geen vervanging nodig. Voor ander toepassingen (streaming, push etc.) bestaan zat protocollen, die ook allang volop worden toegepast.

Vind het een beetje een holle frase om te zeggen dat HTTP zijn tijd heeft gehad.

Microsoft zal proberen eigen protocollen (met licentiekosten) in de markt te zetten en zo een nieuwe markt aan te boren.

[Verwijderd]

http is ooit bedoeld om webpages mee te bekijken.. tegenwoordig worden er complete webapplicaties mee gebruikt en complete shopsystemen. dat is niet waar http ooit voor ontworpen is.

[Verwijderd]

Holle frase? De grap is dat iedereen vandaag kopt met deze uitspraak (alle nieuws-sites), maar dat het absoluut niet zo bedoeld wordt als de meeste mensen denken die deze zin lezen. Laat dit alsjeblieft een les zijn voor sites die dit soort telegraaf-koppen overnemen.

Voor de juiste interpretatie van de uitspraken van Don Box zie Abraxas hierboven.

[freaky]

Ik denk niet dat de ietf daar mee accoord gaat zeg maar :-)

[Verwijderd]

Die langdurende requests zijn inderdaad wel nodig als je met .NET (of SOAP in het algemeen) wilt programmeren, en je wilt als client wachten op iets wat aan de server-kant gebeurt. Nu kan je met SOAP ergens om vragen (bv. "wat is de koers van dit aandeel"), en je krijgt meteen het resultaat. Maar soms wil je bv. weten, wanneer de koers boven een bepaalde waarde is. Nu gaat dat niet, tenzij je zelf een SOAP-server implementeert (aan de client-kant dus), en ze sturen een SOAP call naar jou wanneer de koers die waarde heeft bereikt. Dan moet je dus zowel server als client zijn. Als je zo'n HTTP, en dus SOAP-call nou heel lang kan laten wachten, maak je een SOAP call die pas returnt als de koers de gewenste waarde heeft bereikt, en tot die tijd hou je gewoon de boel open.
Ik neem aan, dat ze dan ook maken, dat je HTTP requests beter kan multiplexen over dezelfde socket verbinding, anders hou je voor elke uitstaande request een socket bezet, en dat lijkt me juist niet de bedoeling...

[Verwijderd]

anders hou je voor elke uitstaande request een socket bezet, en dat lijkt me juist niet de bedoeling...

Het lijkt mij dat het er juist om gaat dat dat openhouden van sockets niet meer nodig is. De server maakt dan een connectie met de client, ipv. op een bestaande connectie te werken.

[jiriw]

Ik heb hier eigenlijk twee problemen mee ....

1) Je verlaat (zoals aangegeven)het client-server principe ... De thuisgebruiker(client) moet een server openzetten die 24 uur per dag moet draaien om die verlate requests te ontvangen.
En je krijgt problemen met firewalls, ip masquerading, etc. omdat je dan nooit bereikbaar kan zijn (wil je anders echt 5 dagen je socket door de firewall openhouden??? SLIK)
2) Dit wordt een te mooie manier voor spam activiteiten ...

Je kan natuurlijk ook gewoon "Pollen" ... heeft wel zo z'n nadelen (dat je wat data verkeer genereert en het event gebeurt mischien tussen twee polls) maar dat is met de oude techniek wel makkelijk te implementeren

[jimshatt]

Het leuke van SOAP is dat het niet per se over HTTP hoeft. Je kunt zelfs SOAP over SMTP/POP implementeren, en dat is gelijk een oplossing voor problemen met lang openstaande sockets. Je maakt je SOAP request over SMTP of HTTP of whatever en krijgt je SOAP antwoord over POP. Je bent dan inderdaad aan het "pollen", maar wel op je eigen (speciaal daarvoor ingerichte) mailbox.
Ik denk dat polling beter is dan een servertje aan de client kant te implementeren, alleen al om security en kost ook minder CPU.

[Verwijderd]

Een limitatie van HTTP is bijvoorbeeld dat er maar één kant van de lijn een uitwisseling via HTTP kan starten, de andere kant is slechts passief.

De vraag blijft natuurlijk of dit nu vervelend is of juist niet. Uit het oogpunt van de gebruiker is het denk ik juist handig, je krijgt alleen waar je om gevraagd hebt, uit het oogpunt van M$ en andere producenten is het vervelend omdat je dan niet ongevraagd zomaar informatie naar clients kan sturen. Ofwel M$ wilt graag meer controle uitoefenen op clients en wilt dus ook spam achtige zaken gaan doen. Hier zit ik dus niet echt op te wachten.

[Tijger]

Je maakt jezelf al belachelijk door M$ te gebruiken.

Het gaat erom dat nu applicaties over HTTP gedraait worden en je cookie trucks (hoezo veiligheid) moet uithalen om de functionaliteit te krijgen die voor sommige apps nodig is.

[leonardo1504]

Het gaat erom dat nu applicaties over HTTP gedraait worden en je cookie trucks (hoezo veiligheid) moet uithalen

Cookies zijn bedacht door Netscape om het grote bezwaar van HTTP op te vangen: het is een stateless protocol. Het is een misvatting dat het gebruik van cookies een applicatie per definitie minder veilig maakt. Niemand verplicht je immers om persistent cookies te gebruiken (heb je niet nodig voor sessiemanagement), en ook verplicht niemand je om in zo een cookie (client-side dus) allerlei gevoelige informatie in een leesbare vorm op te slaan. Wie zijn site goed voor elkaar heeft gebruikt alleen sessie-cookies om de browser te herkennen, en houdt server-side alle informatie bij. Die is dan los van welk 'transfer-protocol' je gebruikt (HTTP of iets anders) te beveiligen. Ieder alternatief voor cookies dat van HTTP een stateful protocol zou maken zou dan even veilig of onveilig moeten zijn als het gebruik van cookies.

Cookies kunnen alleen maar onveilig zijn als de applicatiebouwer ze op een onveilige manier gebruikt. Die dikke Duitse autos zijn ook hardstikke veilig tot je er met 200+ km/h mee gaat scheuren in de bebouwde kom.

edit:

typo

[Verwijderd]

Het gaat hierbij echt niet om het kunnen versturen van spam etc. Het lijkt me sterk dat W3C een protocol zal goedkeuren wat het mogelijk maakt om ongewenst spam te versturen op grote schaal.
Voor web-services, dus meer client-server-achtige applicaties zullen er voldoende redenen zijn om dit te doen, zie het voorbeeld van Truusje mbt aandelen. De client zal dan het request indienen en de client zal er dan in mijn opinie voor moeten zorgen dat de ontvangst van dit request op een later tijdstip wordt geauthoriseerd. Dus de client bepaalt zelf wanneer en hoe dit gebeurd. Dus de server-side moet geen informatie terug kunnen sturen waar niet om gevraagd is. Dit lijkt mij dan een van de belangrijkste dingen die het nieuwe protocol zal moeten ondersteunen en voor zorg zal moeten dragen dat het niet misbruikt kan worden.
Verder lijkt het me voor grote bedrijven als Microsoft helemaal niet zinvol om maar onbeperkt spam te versturen. Dat zal zo'n bedrijf alleen maar een slechte naam bezorgen. Ik heb volgens mij nog nooit spam van Microsoft ontvangen, alleen informatie waar ik zelf om gevraagd heb.

[xces]

Ik denk dat we het anders moeten lezen als ik deze discussie zo zie:

"Http gaat verdwijnen volgens microsoft"
equals
"Microsoft kan niet genoeg met het http protocol en willen daarvoor een nieuw protocol"

Want laten we eerlijk zijn, we worden altijd weer verrast als we kijken naar verschillende internetpagina's die er weer net even mooier uit zien dan de vorige pagina.

edit:

Er staat niet voor niets in het artikel:
[quote]
"There is work going on to address the shortcomings of HTTP, said Box."
[/quote]
&
[quote]
"We have to do something to make it (HTTP) less important,"
[/quote]

[Tijger]

*zucht* god wat een getroll is dit zeg, als ook IBM en de W3C ermee bezig zijn en Box zegt dat dit geen proces is van *1* bedrijf dan maak je dat ervan?

Sorry hoor maar ik vind het nivo in deze discussie echt triest, er wordt totaal niet naar de inhoud van het besprokene gekeken en het belang daarvan, omdat iemand die bij MS werkt dit zegt betekent het niet dat her per definitie fout of slecht is.

[Verwijderd]

Hm, ben het wel erg met je eens. Ik heb sterk het gevoel dat een flink aantal personen hier het verschil tussen HTTP en HTML niet eens doorhebben. *pruttel*

Valt me wat tegen.

[RetepV]

Wat wordt het allemaal weer uit zijn verband getrokken zeg!

Voordat het HTTP protocol er ueberhaupt bestond waren er al tientallen andere protocollen. Als Microsoft nu een nieuw protocol gaat bedenken, dan is de kans heel erg groot dat ze iets bedenken wat al bedacht is.

Het HTTP protocol is juist zo uniek omdat het tekst-georienteerd is, dwz. je kunt het zelfs met een telnet sessie met de hand emuleren.

Dat het bedoeld was voor bepaalde dingen, was wel duidelijk. Dat je het niet voor alles moet gebruiken was ook wel duidelijk. Dat Microsoft het wel voor alles probeert te gebruiken is ook wel duidelijk.

Dat Microsoft nu ineens zegt dat HTTP niet in alle gevallen voldoet betekent alleen maar dat Microsoft er dus een paar jaar voor nodig heeft gehad om zich dat te realiseren.

Ik denk dat dit wel een goede maat is voor de collectieve intelligentie van het bedrijf Microsoft. Bij Microsoft werken een heleboel intelligente mensen, maar die collectieve intelligentie wordt weer flink afgezwakt doordat het management en de commercie bepalen wat al die intelligente mensen moeten doen. Het totale collectieve IQ bedraagt daardoor maar iets van 100 ofzo (net iets hoger dan gemiddeld ).

[Tijger]

*kijkt naar de beurskoersen* Um...wist niet dat je met zo'n laag IQ zoveel geld kon verdienen terwijl de rest in de rode cijfers gaat.

Is natuurlijk onzin wat je zegt, IEDEREEN probeert alles over HTTP te gooien.
Als je het goed leest zie dat dit niet iets van MS alleen is en ook niet KAN zijn, zeker geen protocollen die in het hart van het Internet liggen.

[Verwijderd]

"The end of the world as we know it....."

Http is dood, lang leve Http2 ??

[Verwijderd]

goede song trouwens, maar om het gebruikte protocol als het belangrijkste op aarde te zien lijkt me niet