blob: 0c3d5b5374b6107f35a1d17053ca8c6fa5694aaf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
Naming rules for manipulated objects and structures.
Previously, there were ambiguities between sessions, transactions and requests,
as well as in the way responses are noted ("resp", "rep", "rsp").
Here is a proposal for a better naming scheme.
The "session" is above the transport level, which means at ISO layer 5.
We can talk about "http sessions" when we consider the entity which lives
between the accept() and the close(), or the connect() and the close().
=> This demonstrates that it is not possible to have the same http session from
the client to the server.
A session can carry one or multiple "transactions", which are each composed of
one "request" and zero or one "response". Both "request" and "response" are
described in RFC2616 as "HTTP messages". RFC2616 also seldom references the
word "transaction" without explicitly defining it.
An "HTTP message" is composed of a "start line" which can be either a
"request line" or a "status line", followed by a number of "message headers"
which can be either "request headers" or "response headers", and an "entity",
itself composed of "entity headers" and an "entity body".Most probably,
"message headers" and "entity headers" will always be processed together as
"headers", while the "entity body" will design the payload.
We must try to always use the same abbreviations when naming objects. Here are
a few common ones :
- txn : transaction
- req : request
- rtr : response to request
- msg : message
- hdr : header
- ent : entity
- bdy : body
- sts : status
- stt : state
- idx : index
- cli : client
- srv : server
- svc : service
- ses : session
- tsk : task
Short names for unions or cascaded structs :
- sl : start line
- sl.rq : request line
- sl.st : status line
- cl : client
- px : proxy
- sv : server
- st : state / status
|
