Also let this function reset offset and lengths for http_body_read().
Make sure of this function in the python code so req.body can be called
multiple times in succession.
The only reason you would want to directly modify the cookie
after creating it should be to unset the HTTPONLY or SECURE flags
if that is what you *really* want to do.
Change http_response_cookie() to take all required parameters instead
of having to marshall those in yourself after.
Now you set a sane default cookie in one shot:
http_response_cookie(req, "key", "value", "/", 0, -1, NULL);
Which would create a session cookie key=value for / under the current domain.
We now default to httponly & secure for newly created cookies.
This should've been the default all along.
The http_response_cookie() no longer returns a pointer to http_cookie
but rather takes it as a parameter and will populate the pointer with
the newly created http_cookie if not NULL.
Additionally http_response_cookie() automatically sets the domain
based on the http_request passed into the function.
At bootup and every 1800 seconds after that the worker processes will
ask the keymgr for new entropy that they will seed into their PRNG.
Additionally once received the worker calls RAND_poll() to grab
more entropy from the system to be mixed in.
This option allows the user to specify a file to be used for
seeding the PRNG initially and to write random bytes at exit.
The option is only available if kore has TLS enabled (by default).
If you enable this option Kore will refuse to start if there is
a problem with the file specified (not found, not a file, invalid size, etc).
While here let the keymgr process call RAND_poll() every half hour
to grab more system entropy and seed it into the PRNG.
We were not returning zeroed out memory from kore_calloc() which goes
against what calloc() does. Skip performance for now and simply just
memset() the returned pointer from kore_malloc().
This should be sufficient enough for now.
This will look at the kore.pid file in the current directory
and send a SIGHUP signal to it. It's mostly a handy shortcut
since you could of course do a kill -HUP `cat kore.pid` easily.
Before this function would block client I/O and existing HTTP requests
until the keymgr process responsed with a result.
This commit changes that behaviour and makes this function call
the http_process() function if we end up waiting for the keymgr.
This means that while waiting for a response we at least start
making headway with existing HTTP requests if the response is
not immediate.
Having the create, build, run tools baked into the kore binary
made things harder then they had to be for multiple projects with
each different build flavors.
So move away this functionality into a new "kodev" (name may change)
binary that is installed next to kore.
The new build tools will automatically pick up the correct flavors
the kore binary it points to is installed with. Or for single builds
what flavors where enabled.
The new tool also will honor looking into PREFIX for the kore binary
when doing a `kodev run`.
Additionally add a new command "info" that shows some basic info
about your project and how it will be built. For example it will
show you the flavors of the kore binary installed on the system
or the flavors you configured for a single binary build.
Obligitory, hacking on a plane comment.
- split up writing of cookies into its own function.
- turn maxage into a signed int and use -1 for it not being set.
- lots of style fixes
- remove HTTP_COOKIE_DEFAULT, just pass 0 if you don't want flags.
This commit adds the ability to use python "await" to suspend
execution of your page handler until the query sent to postgresql
has returned a result.
This is built upon the existing asynchrous query framework Kore had.
With this you can now write stuff like:
async def page(req):
result = await req.pgsql("db", "SELECT name FROM table");
req.response(200, json.dumps(result).encode("utf-8"))
The above code will fire off a query and suspend itself so Kore can
take care of business as usual until the query is successful at which
point Kore will jump back into the handler and resume.
This does not use threading, it's purely based on Python's excellent
coroutines and generators and Kore its built-in pgsql support.
- adds new cleanup function that workers will call.
- adds kore_pgsql_nfields() to return number of fields in result.
- add kore_pgsql_fieldname() to return name of a given field.
This commit also changes the behaviour of pgsql_conn_release() in
that it will now cancel the active query before releasing the connection.
This makes sure that if long running queries are active they are hopefully
cancelled if an http request is removed while such queries are still running.
Renamed both of them:
kore_preload -> kore_parent_configure
kore_onload -> kore_worker_configure
These functions will now always be called if they are defined in any module
regardless of your application being built as a single binary or not.
we just increase the lenght requested to 8 bytes if we get a 0 byte request.
additionally when kore_realloc() is called check if we actually have
to do the work, if not just return the original pointer.
These functions are created by the cli tool when building
and follow the naming format: asset_serve_<name>_<ext>().
Those serving functions can be used directly in handlers and
callthrough to a http_serveable() function that uses the SHA1
of the asset as its ETag and automatically checks for if-none-match.
The possibility to call jsonrpc_destroy_request was left. Someone may
want to abruptly interrupt the process of its request for some odd
reason, in that case an exlicit call still would be to be made.
A true application dependant limit check would require stream parsing.
As the limit enforcement was done, it added nothing of value compared
to HTTP request limit check, which is in Kore already.
The API surface is very limited. Jsonrpc support reads request from HTTP
body and such can't be activated if NOHTTP=1. At the moment there is no
websocket support either (which is a shame). It depends upon the
third-party Yajl library.
Errors can be emitted using jsonrpc_error() and results using
jsonrpc_result(), for the later you'll have to provide a callback which
will write the inner of the result object.
If errors happen during the response write process, no further error
output will be attempted and an HTTP error 500 will be returned.
Read the provided example for getting a better idea of the API.
Use CAS to implement primitive spinlock ontop of the pool
if we have been built with TASKS=1.
This allows tasks to safely use kore_malloc() and kore_free()
since those are now backed by pools.
- Change pools to use mmap() for allocating regions.
- Change kore_malloc() to use pools for commonly sized objects.
(split into multiple of 2 buckets, starting at 8 bytes up to 8192).
- Rename kore_mem_free() to kore_free().
The preallocated pools will hold up to 128K of elements per block size.
In case a larger object is to be allocated kore_malloc() will use
malloc() instead.
kore_buf_create and kore_buf_free do use kore_malloc. But sometimes you
may embed a kore_buf inside a structure and would like a single way to
initialize / destroy it.
Producing single binaries can now be done with building with
"kore build". To get started edit your build.conf and add the
following directives:
single_binary = yes
kore_source = /path/to/kore
optionally you can add kore_flavor to instruct how kore should
be built:
kore_flavor = NOTLS=1
When doing this your build.conf must also include the correct
linking options as the linking is now done fully by kore build.
The binary produced will include your configuration and takes
over a few of kore its command line flags (such as -f, -n or -r).
Joris Vink
Stanislav Yudin
Yorick de Wid
Yvan Sraka
Tobias Kortkamp
Raphaël Monrouzeau