| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This makes it a bit more obvious what happened in cases like #1838,
reported by Woodrow E Douglass.
While at it, add some more test cases for this particular case, but
also for retry-attempts, as this is also affected when retry is
allowed for non-idempotent requests (which is pretty uncommon, but
possible)
|
|
This allows one to pass in a filename for the data.
|
|
For some reason the hardcoded length was incorrect. It makes more
sense to not hardcode it, as the exact value might differ depending on
the boundary etc.
|
|
This makes it slightly more reliable for certain servers which
absolutely require content length.
An alternative would be to have an explicit API for sending static
string contents. This could be in addition to this approach, because
this should always be a net win.
|
|
As pointed out by Siiky, intarweb already strips the directory name,
so we don't have to do it here. Allows us to drop an import, which
is always nice for clarity.
Also update the copyright year.
|
|
|
|
When we check to see if the underlying path must be updated
to be present, we should know that uri-common is faking a
path of (/ "") when the path is empty.
The path normalization in uri-common could use some work though,
as it never really touches the underlying uri-generic object.
On the other hand, this is sort of the promise that uri-common
tries to make - it never mangles the uri object unless you explicitly
update something yourself.
|
|
That path should also have a trailing slash just like when
requesting a regular URI. See #1781
|
|
|
|
|
|
(which is disallowed by RFC)
|
|
|
|
Keywords can't be (ab)used as identifier anymore, so we can't bind
expression: with let-syntax. Instead, simply use the plain symbol.
|
|
|
|
Thanks to Norman Gray for pointing out that the response was missing
from the condition object.
|
|
|
