I'm thinking it might be an interesting idea to pass ipappend-style
metadata (and quite possibly additional information, e.g. obtained from
DMI) when making a http request, but I'm not 100% sure about the best
way to do it.
Options are pretty much:
1. some kind of metavariables in either the configuration file or in
the filename syntax.
+ very general.
- cumbersome for the user.
- most complex to implement.
2. as a query string automatically appended to the requested URL.
+ easy.
- makes it impossible to use any other kind of queries.
- high overhead (data sent on every request.)
3. as a query string appended to the requested URL when requested.
This probably means using a pseudo-URL namespace, e.g.:
http+info://...
+ easy.
- nonstandard syntax.
- cumbersome.
4. using the http cookie protocol.
+ easy.
- somewhat high overhead (cumbersome encoding, data sent on every
request).
5. as a HTTP query sent via PUT or POST.
This probably means using a pseudo-URL namespace, e.g.:
http+post://...
+ easy.
+ can be cached server side if only sent once.
- nonstandard syntax.
- cumbersome.
- very high overhead when used; the standard MIME forms encoding is
very cumbersome.
6. as an HTTP PUT sent on demand.
This would be an explicit command, say:
sendconfig http://...
+ only sent once (at least per read of the config file).
+ can be made to work for FTP or even TFTP.
+ can in theory send a fair bit of data.
+ implementation can be shared with other client-side data producers.
- send *after* the config file, which pretty much means that one
then need to use a separate CONFIG command to get a customized
configuration file.
- cumbersome implementation.
Thoughts? Other ideas.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Mon, Apr 25, 2011 at 9:59 PM, H. Peter Anvin <hpa at zytor.com> wrote:> I'm thinking it might be an interesting idea to pass ipappend-style > metadata (and quite possibly additional information, e.g. obtained from > DMI) when making a http request, but I'm not 100% sure about the best > way to do it. > > Would be great to filter/set what information to pass as an dhcp option(integer of course, like ipappend style is now). Would make expanding some of the options below easier for initial HTTP config grabs. i.e. 1 would be serial, 2 would be cpu-serial, 3 would be serial and cpu serial, etc.> 4. using the http cookie protocol. > > + easy. > - somewhat high overhead (cumbersome encoding, data sent on every > request). >You mean sessions or X-Headers ? If you mean sessions I think that requires being HTTP/1.1 complaint; would require a bit of investigation. X-Headers work all the time. I would personally prefer the X-Header sessions, but it is very similar to the query string approach.> 6. as an HTTP PUT sent on demand. > > This would be an explicit command, say: > > sendconfig http://... > > + only sent once (at least per read of the config file). > + can be made to work for FTP or even TFTP. > + can in theory send a fair bit of data. > + implementation can be shared with other client-side data producers. > - send *after* the config file, which pretty much means that one > then need to use a separate CONFIG command to get a customized > configuration file. > - cumbersome implementation. > >I love this for an after the server loaded the configuration file, but if I can get some options via DHCP to determine the config, what's the point ? The only situation I can think of is when you don't have an inventory reclamation image to take inventory before launching into an installer. FWIW, my preferred approach would be to set a list of options to set/filter out the meta-data in X-Headers for when I fetch my config file via HTTP (also set in dhcp options). Right now I have a cludge that heavily relies on the mac address using substr() inside of the dhcp config. Being able to connect DMI data to my inventory and provisioning systems would be stellar. hope this makes sense :) -- Kevin Landreth
H. Peter Anvin
2011-Apr-26 05:50 UTC
[syslinux] Opinion wanted: metadata in HTTP requests (updated)
Okay, I have narrowed it down to two options:
1. Using HTTP cookies, in every request. To avoid collision with other
cookie uses, the cookie names would be prefixed with _Syslinux_ or
some similar prefix although this adds overhead.
2. Using a GET query string, if and only if the http URL is of a
special form, probably:
http://example.com/something??
... i.e. ending in a double ?? which should not normally happen in a
URL.
I would like to know if people have specific preferences between these
alternatives.
-hpa
John Rouillard
2011-Apr-26 13:57 UTC
[syslinux] Opinion wanted: metadata in HTTP requests (updated)
On Mon, Apr 25, 2011 at 10:50:25PM -0700, H. Peter Anvin wrote:> Okay, I have narrowed it down to two options: > > 1. Using HTTP cookies, in every request. To avoid collision with other > cookie uses, the cookie names would be prefixed with _Syslinux_ or > some similar prefix although this adds overhead. > > 2. Using a GET query string, if and only if the http URL is of a > special form, probably: > > http://example.com/something?? > > ... i.e. ending in a double ?? which should not normally happen in a > URL. > > I would like to know if people have specific preferences between > these alternatives.Is there a difference in the amount of data that can be sent via these mechanisms? Using POST is the usual workaround when the get string is too large and code "414 Request-URI Too Long" is returned.>From rfc 2109 the browser should support:* at least 300 cookies * at least 4096 bytes per cookie (as measured by the size of the characters that comprise the cookie non-terminal in the syntax description of the Set-Cookie header) * at least 20 cookies per unique host or domain name so the server should be able to handle at least that. So I think the cookie mechanism may be a better choice depending on how much data you expect to send. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111