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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-Language" content="en" />
<title>tipidee: FAQ</title>
<meta name="Description" content="tipidee: FAQ" />
<meta name="Keywords" content="tipidee FAQ caveats frequently asked questions" />
<!-- <link rel="stylesheet" type="text/css" href="//skarnet.org/default.css" /> -->
</head>
<body>
<p>
<a href="index.html">tipidee</a><br />
<a href="//skarnet.org/software/">Software</a><br />
<a href="//skarnet.org/">skarnet.org</a>
</p>
<h1> tipidee caveats and FAQ </h1>
<div id="caveats">
<h2> Caveats </h2>
</div>
<h3> <tt>Host</tt> support in HTTP/1.0 </h3>
<p>
A strict reading of the
<a href="https://datatracker.ietf.org/doc/html/rfc1945">HTTP/1.0 specification</a>
says that the Request-Line is the only piece of client-provided data that can
be used to identify a resource, and that extension headers can modify the
interpretation and processing of that resource but not <em>change</em> what
resource is served.
</p>
<p>
This goes directly against the use of the <tt>Host</tt> header to identify
the host of a resource and that is used in HTTP/1.1.
</p>
<p>
A lot of HTTP servers out there don't care about a strict reading of HTTP/1.0
(or even a strict reading of anything, really), and have
historically used <tt>Host</tt> to perform virtual hosting even in HTTP/1.0,
even though it goes against the specification. Consequently, clients have
adapted, and
<a href="https://github.com/curl/curl/issues/5976">even the popular
<tt>curl</tt> client</a> sends a <tt>Host</tt> header in HTTP/1.0.
</p>
<p>
Since the point of the Web is interoperability, tipidee aligns with
the common practice, and will read a client-provided <tt>Host</tt> header,
if any, to determine what domain the request is directed to, even in
HTTP/1.0 no matter what the spec says. I refer to this practice as
"speaking HTTP/1.05".
</p>
<div id="faq">
<h2> Frequently asked questions </h2>
</div>
<h3> I want my web server to listen to more than one address. Do I need
to do all that for every address I have? </h3>
<p>
Not necessarily: you could listen to <tt>0.0.0.0</tt> for IPv4, and
<tt>::</tt> for IPv6. But if you don't want your server to listen to
<em>all</em> the addresses on your machine, then yes, you will have
to run one process per address:port tuple.
</p>
<p>
It's okay though: every listening process is very small. The skarnet.org
server has two network cards and runs a web server on both of them, on
IPv4 and IPv6, over HTTP and HTTPS, which makes 8 services. Plus one
<a href="//skarnet.org/software/s6/s6-log.html">s6-log</a> logger process
for each of these services. Plus a supervisor for every service and every
logger — for a whooping total of 64 long-running processes just for
its web server functionality; and it's still not even noticeable, the
amount of resources it consumes is negligible. So, don't worry about it;
all your resources are still available for the serving itself.
</p>
<p>
Note that this allows you to run different instances of
<a href="tipideed.html">tipideed</a>, on different sockets, with different
configurations, if you need it. Use the <tt>-f</tt> option to specify a
different config file in your instances.
</p>
</body>
</html>
|
