Subject: Request header in response

From: "Dave Wain" <[email-masked]>
Date: Sun, 15 Nov 2015 05:05:01 +0000

Dear All,

If the request header (or most of it) is included in the
response header, HTTP would become its own transport
layer, independent of TCP/IP.

This would be especially useful for remote locations.

DW

Note: This message is private and confidential and hence
must be received without interception or distortion by the
intended recipients only. Permission to use the information
explicitly must come from the sender (and recipients).

My personal web site and alternate contact details are at:
http://homepage.ntlworld.com/dave.wain/.

---

From: Florian Best <[email-masked]>
Date: Sun, 15 Nov 2015 17:17:54 +0100

Hello Dave,

I would like to understand in which way you think that HTTP depends on
TCP/IP and how it wouldn't if the response contains the request headers?
IMHO the underlying communication protocol has nothing to do with it.
As long as you can parse the message syntax and make the connection
management you are independent of the underlying transport layer:
You could even transfer HTTP messages via UDP, UNIX sockets (as I
sometimes do), or whatever you want.

Best regards

---

From: Florian Best <[email-masked]>
Date: Sun, 15 Nov 2015 20:59:59 +0100

Okay, for this you just need a unique identifier for the message. e.g.
one header "Message-Id: 12345"  in the request and response.

Am 15.11.2015 um 20:50 schrieb Dave Wain:
> But to match the response to the request requires (some of) the request
> header to be part of the response header.
>
> For example, if requests go via a satellite phone but the response comes
> via a satellite broadcast channel, there would be no way to de-multiplex
> the responses.
>
> Regards
> Dave
>
> -----Original Message-----
> Sent: 15 November 2015 16:18
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Request header in response
>
> Hello Dave,
>
> You could even transfer HTTP messages via UDP, UNIX sockets (as I sometimes
> do), or whatever you want.
>
>> If the request header (or most of it) is included in the response 
>> header, HTTP would become its own transport layer, independent of 
>> TCP/IP.
>>
>> Note: This message is private and confidential and hence must be 
>> received without interception or distortion by the intended recipients 
>> only. Permission to use the information explicitly must come from the 
>> sender (and recipients).
>>

---

From: Florian Best <[email-masked]>
Date: Mon, 16 Nov 2015 18:50:03 +0100

If you don't do it with an ID you cannot differentiate between two
unsafe requests which have the same headers.
And of course there is a lot more traffic if you would send all the
header back.
Well, I think you could implement this by yourself if you need it.
Implementing it in HTTP seems not necessary and not backwards compatible.
And you should have a look at HTTP/2.

It would be nice If you would answer to the mailinglist instead of me
personally.

Am 16.11.2015 um 17:59 schrieb Dave Wain:
> Florian,
>
> Good idea, you could use a request-id. Reminds me of when I
> invented web sessions back in 95/96.
>
> In this case however it would just be easier to include the actual
> request because the id would not be guaranteed to be unique
> and caching would be difficult.
>
> Good discussion though ;)
> DW
>
> Sent: 15 November 2015 20:00
> To: Dave Wain <[email-masked]>
> Cc: [email-masked]
>> But to match the response to the request requires (some of) the 
>> request header to be part of the response header.
>>
>> For example, if requests go via a satellite phone but the response 
>> comes via a satellite broadcast channel, there would be no way to 
>> de-multiplex the responses.
>>
>> Regards
>> Dave
>>
>>> received without interception or distortion by the intended 
>>> recipients only. Permission to use the information explicitly must 
>>> come from the sender (and recipients).
>>>