destination changed.
Feel free to comment.
Regards,
--
Paul Fariello
PGP: 0x672CDD2031AAF49B
? .gitignore
? 0001-Remove-superfluous-http-method-handling-for-request-.patch
? README.md
Index: relay.c
===
RCS file: /cvs/src/usr.sbin
Hi Raul,
On Wed, Jul 27, 2016 at 09:42:23AM -0400, Raul Miller wrote:
> On Wed, Jul 27, 2016 at 8:00 AM, Paul Fariello wrote:
> > Ok. I didn't notice that relayd had a security filtering focus. If so,
> > enforcing presence/absence of body is legit.
>
> Perhaps the
On Wed, Jul 27, 2016 at 01:31:28PM +0200, Reyk Floeter wrote:
>
> > On 27.07.2016, at 12:41, Paul Fariello wrote:
> >
> > On Wed, Jul 27, 2016 at 12:18:06PM +0200, Reyk Floeter wrote:
> >>
> >> What are you trying to do - removing this logic is obviousl
sponse
> differently -
> the webdav diff that I sent before is only part of the fix.
Sorry, I missed your patch.
--
Paul Fariello
PGP: 0x672CDD2031AAF49B
On Wed, Jul 27, 2016 at 11:26:28AM +0200, Paul Fariello wrote:
> On Wed, Jul 27, 2016 at 11:08:17AM +0200, Michael Lechtermann wrote:
> >
> > > On 27Juli, 2016, at 10:19, Paul Fariello wrote:
> > >
> > > relayd logs and svn server log could really help.
>
On Wed, Jul 27, 2016 at 11:08:17AM +0200, Michael Lechtermann wrote:
>
> > On 27Juli, 2016, at 10:19, Paul Fariello wrote:
> >
> > relayd logs and svn server log could really help.
> >
> > I can't reproduce it since I don't have a working svn server
ponse to
> OPTIONS request for 'https://www../svn/repo'
Missed this log. So it fails on OPTIONS method which is part of
HTTP/1.1, RFC 7231.
relayd logs and svn server log could really help.
I can't reproduce it since I don't have a working svn server.
>
> Regards,
> Michael
>
--
Paul Fariello
PGP: 0x672CDD2031AAF49B
On Wed, Jul 27, 2016 at 10:01:43AM +0200, Stefan Sperling wrote:
> On Wed, Jul 27, 2016 at 09:55:24AM +0200, Paul Fariello wrote:
> > Do you know which http method svn is using ?
>
> See https://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav
Thanks for the refer
g
> through relayd.
>
> # svn up
> svn: Server sent unexpected return value (400 Bad Request) in response to
> OPTIONS request for 'https://www../svn/repo'
>
> Regards,
> Michael
>
> > Paul Fariello hat am 27. Juni 2016 um 21:19 geschrieben:
> >
>
Hi,
here is an updated patch adding support for WebDAV Versioning Extensions
RFC3253.
Regards,
Paul
On Mon, Jun 27, 2016 at 09:35:20AM +0200, Paul Fariello wrote:
> Hi,
>
> I've encountered the exact same issue. I think this is due to a miss
> handling of message-body.
>
Hi,
I've encountered the exact same issue. I think this is due to a miss
handling of message-body.
RFC2616 states in chapter 4.3 that:
> The presence of a message-body in a request is signaled by the
> inclusion of a Content-Length or Transfer-Encoding header field in
> the request's message-hea
called
once per relay, but doing so would force to close the current relay and
so we would lose the current http connection.
Do you consider such a fix viable ?
Regards,
On Sun, Apr 03, 2016 at 05:31:29PM +0200, Paul Fariello wrote:
> Oops, seems like I fails something with sendbug. First ti
> which produce:
> relay www, session 2 (1 active), 0, 127.0.0.1 -> 127.0.0.1:8081, last
> write (done), GET GET
>
>>Fix:
> My current work around is to force connection close with:
> header set "Connection" value "close"
>
> Giving a look at relayd source code I suppose that this scenario is
> known. In relay_http.c, int relay_match_actions(); relayd is changing
> the destination table with the one from the matched rule but it doesn't
> use the corresponding fd when relaying.
--
Paul Fariello
13 matches
Mail list logo
