Re: [External] Re: Apache HTTP Server dependency on OpenSSL

[Julian Reschke]

On 09.11.2022 08:39, Payyavula, Manjula Vani via dev wrote:

Hi Team,

We are facing security vulnerability with "faterxml jackson databind" dependency 2.13.3, 
1.13.4, .. so on. Even if we used latest 2.14.0-rc2 version also did not resolve the 
"CVE-.." type vulnerabilities.
Could you please help/suggest.


...with which Apache project? This mailing list is about the Apache HTTP
Server ("httpd").

Best regards, Julian

Re: CVE-2022-1388

[Julian Reschke]

Am 18.05.2022 um 14:50 schrieb Ruediger Pluem:



On 5/18/22 2:31 PM, Eric Covener wrote:

Given the above, I believe the interpretation of X-F5-Auth-Token should
be that it is an end-to-end header, and should therefore NOT be removed
from the proxied request.

The text does say "All other headers *defined by HTTP/1.1* are
end-to-end headers" (emphasis mine, of course), and the X-F5-Auth-Token
header isn't defined by HTTP/1.1 (it's a custom one), but I think the
definition of specific hop-by-hop headers implies that *all* other
headers should be considered end-to-end.


I don't think that interpretation can be squared with e.g.

https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.1
https://datatracker.ietf.org/doc/html/rfc7230#section-6.1



I get to the same conclusion. The current proxy code does it correctly.


fwiw; you may want to check the new text in




(really very soon to be published as RFC)

Best regards, Julian

Fwd: Working Group Last Call: HTTP Core Documents

[Julian Reschke]

(FYI)


 Weitergeleitete Nachricht 
Betreff:Working Group Last Call: HTTP Core Documents
Weitersenden-Datum: Thu, 14 Jan 2021 17:49:41 +
Weitersenden-Von:   ietf-http...@w3.org
Datum:  Thu, 14 Jan 2021 09:49:22 -0800
Von:Tommy Pauly 
An: HTTP Working Group 



Hello HTTP WG,

The time has come to start our Working Group Last Call for our current
“core” documents! The issues list for these documents has been whittled
down and we’re ready to have the working group review them in depth in
preparation to progress them towards publication.

These are substantial drafts, so your time in reviewing is very much
appreciated. We'll plan to have a three-and-a-half-week last call, so
that we will get feedback prior to our planned interim dates. The last
call will end on *Monday, February 8, 2021*.

The three drafts to review are:

HTTP Semantics, draft-ietf-httpbis-semantics
https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-14.html


HTTP/1.1, draft-ietf-httpbis-messaging
https://www.ietf.org/archive/id/draft-ietf-httpbis-messaging-14.html


HTTP Caching, draft-ietf-httpbis-cache
https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-14.html


Please send email to the working group list with comments and feedback,
and state if you think these documents are ready to progress. You can
also file issues here: https://github.com/httpwg/http-core/issues
.

Many thanks to Julian, Mark, and Roy for their hard work on editing
these documents!

Best,
Tommy

Re: Reject HTTP protocols >= 2.0 in ap_parse_request_line?

[Julian Reschke]

On 08.06.2020 16:59, Yann Ylavic wrote:

On Mon, Jun 8, 2020 at 9:56 AM Ruediger Pluem  wrote:


I came across the question if we should not reject HTTP protocols >= 2.0 in the 
request line when we parse it
in ap_parse_request_line.


Why not >= 1.2 ?


In *theory*, there could a future HTTP/1.2 version that shares the wire
format with 1.0 and 1.1.


...


Best regards, Julian

Re: keep-alive and vary in 304 responses

[Julian Reschke]

On 10.04.2019 16:10, Stefan Eissing wrote:




Am 10.04.2019 um 15:57 schrieb Julian Reschke :

On 10.04.2019 14:53, Plüm, Rüdiger, Vodafone Group wrote:

...
Not sure about this. I guess with TE each hop could be different in what it 
accepts
and generates. This is different from CE. As far as I understand the 
accept-encoding header
is only for CE not for TE.
...


Right (that would be "TE").

That aside, maybe it's time to remind that HTTP/2 doesn't have transfer
codings?


You mean, it does not have "chunked".


Not my reading...:

"The only exception to this is the TE header field, which MAY be present
in an HTTP/2 request; when it is, it MUST NOT contain any value other
than "trailers"."

<https://greenbytes.de/tech/webdav/rfc7540.html#rfc.section.8.1.2.2.p.2>

Re: AW: keep-alive and vary in 304 responses

[Julian Reschke]

On 10.04.2019 14:53, Plüm, Rüdiger, Vodafone Group wrote:

...
Not sure about this. I guess with TE each hop could be different in what it 
accepts
and generates. This is different from CE. As far as I understand the 
accept-encoding header
is only for CE not for TE.
...


Right (that would be "TE").

That aside, maybe it's time to remind that HTTP/2 doesn't have transfer
codings?

Best regards, Julian

Re: keep-alive and vary in 304 responses

[Julian Reschke]

On 10.04.2019 12:49, Yann Ylavic wrote:

On Wed, Apr 10, 2019 at 12:10 PM Stefan Eissing
 wrote:



Am 09.04.2019 um 18:48 schrieb Roy T. Fielding :


2. Validation responses lose the "Vary" header from the unconditional response. 
This happens on resources where mod_deflate is active.
  The 200 response without any "if-modified-since" etc. carries "Vary: 
Accept-Encoding" as it should.
  The 304 response with "if-modified-since" has no "Vary" header.
  The code in mod_deflate looks as if it tries to add it in any case, where is 
it lost?


That's one of many bugs related to design problems with mod_deflate.  Basically,
it chooses to insert itself into the response handling after the other checks 
are done,
which means a 304 doesn't even know yet whether the response would use gzip.
The solution (which I never found time to implement) is to replace dynamic gzip 
with
a transfer encoding generator,


Do user-agents support "Transfer-Encoding: gzip, chunked" currently?
That'd be the best/easier solution I think.
...


AFAIR, the only transfer encoding supported by common UAs is "chunked".

Best regards, Julian

Re: keep-alive and vary in 304 responses

[Julian Reschke]

On 10.04.2019 09:24, Mario Brandt wrote:

On Tue, 9 Apr 2019 at 12:31, Stefan Eissing
 wrote:


I just did some tests with https://redbot.org/ (the site tester by Mark 
Nottingham) against our server and it notifies of 2 things:

1. The "Keep-Alive" header is deprecated. I tried to "Header unset Keep-Alive" 
but that has no effect. Seems to be added very late.
Do we have a way to suppress it?


That is true for HTTP/2. What about the clients that don't support
HTTP/2 yet? I wonder if it is possible to suppress that header only if
HTTP2 or better is used.


Keep-Alive is defined in RFC 2068 and was removed in RFC 2616 (almost 20
years ago).

Best regards, Julian

Re: CVE-2018-11763: mod_http2, DoS via continuous SETTINGS frames

[Julian Reschke]

On 9/25/2018 4:26 PM, Barry Pollard wrote:

I'm confused.

Why are there no changes to mod_http2 mentioned in: 
http://www.apache.org/dist//httpd/CHANGES_2.4.35 
 to 
presumably address this CVE?
Or does one of the other changes cover this? (No as far as I can see but 
could be wrong).
In previous changes files (e.g. 
http://www.apache.org/dist//httpd/CHANGES_2.4.34) 
these were listed at the top of the changes file.


Also should this not be mentioned in: 
https://httpd.apache.org/security/vulnerabilities_24.html?

Apologies if I've jumped the gun and this is still in progress.
...


FWIW, it *is* mentioned in 
, which as a 
last modification date of September 25...


Best regards, Julian

Re: RFC 7230..7235 Parsing Conformance?

[Julian Reschke]

On 2016-05-17 19:01, Graham Leggett wrote:

On 17 May 2016, at 6:43 PM, William A Rowe Jr  wrote:


Wondering what other contributors are thinking on this topic.

We have a number of changes in the ABNF grammar between
RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
an entirely RFC723x generation server, and drop all support for
RFC2616?

Do we want to backport these changes to 2.4.x? If so, what
mechanism do we want to toggle the behavior of the server
between 2616 and 7230..7235?

We can presume a small performance hit in any conditional
operation, especially when those decisions apply to tight parsing
loop. Toggling between two different parser implementations would
probably be a bit more efficient than conditionals within a parser
itself.


Can you give some examples to get a sense of the extent of this?

Regards,
Graham


+1 to the question; I'd like to see examples as well...

I believe we only changed the ABNF when we came to the conclusion that 
the old one was incorrect, or did not reflect what implementations do in 
practice.


Best regards, Julian

Re: doubly defined extensions in mime.types

[Julian Reschke]

On 2013-03-20 11:16, Nick Kew wrote:


On 20 Mar 2013, at 03:47, Chris Darroch wrote:


Hi --

  I notice we have the .wmz and .sub file extentions each defined twice
in trunk mime.types:

.wmz: application/x-msmetafile, application/x-ms-wmz


Couldn't tell you how those arise.  Should we really include
any non-registered types (x-foo) other than as commented lines
indicating what a sysop might want to support?


.sub: text/vnd.dvb.subtitle, image/vnd.dvb.subtitle


Bizarrely, both appear to be correct:

http://www.iana.org/assignments/media-types/text/vnd.dvb.subtitle
http://www.iana.org/assignments/media-types/image/vnd.dvb.subtitle

Anyone here active with IANA?  Looks like their mess!
...


That's per se not a problem (the same type and have multiple names, and 
file extension uniqueness is not enforced).


But what's weird is that the referenced spec doesn't even mention these 
types.


Best regards, Julian

PS: yes, emailed IANA.

Re: If-Match not supported with PROPFIND?

[Julian Reschke]

On 2012-09-25 04:38, Timothy Wood wrote:


My reading of the WebDAV spec leads me to believe that PROPFIND should support 
If-Match, but trying it and looking at the code for dav_method_propfind() I 
don't see a call to dav_validate_request(), dav_meets_conditions() or 
ap_meets_conditions().

Is my reading of the spec incorrect, or is this an oversight? I guess I'll work 
up a patch!

Thanks!


RFC 4918 defines it as a header field that applies to any method (same 
as all RFC 2616 conditional header fields).


That being said, as ETags and timestamps do not necessarily change on 
WebDAV property changes, using it with PROPFIND may be tricky. And, as 
you have seen, support is likely to be spotty.


Best regards, Julian

Re: Time for Apache httpd 2.4.3 ??

[Julian Reschke]

On 2012-07-13 18:02, Jim Jagielski wrote:

If these can be added somewhat quickly, I'm willing to fast-track
them into 2.4.3.
...


I'm currently challenged by Cygwin so I can't make the changes myself 
(well, unless somebody wants to do the hand-holding to get my build 
working).


Can we get the 308 change in separately?

Best regards, Julian

Re: Time for Apache httpd 2.4.3 ??

[Julian Reschke]

On 2012-07-13 23:02, Rainer Jung wrote:

...
If noone objects, I'll commit during the weekend.
...


Sounds good to me, and many thanks!

Best regards, Julian

Re: Time for Apache httpd 2.4.3 ??

[Julian Reschke]

On 2012-07-11 19:15, Roy T. Fielding wrote:

I don't know of any issues with 308, and Julian generally knows what
he is doing with regard to HTTP.  In general, we should consider


Thanks :-)


the IANA registry to be authoritative unless it is a known bug,


In which case we should fix the registry.


which means we should support everything in

http://www.iana.org/assignments/http-status-codes/http-status-codes.xml


Yes. If we want to get all of these in, I can open a separate ticket and 
provide another patch.


Best regards, Julian

Re: Time for Apache httpd 2.4.3 ??

[Julian Reschke]

On 2012-07-11 05:09, Jim Jagielski wrote:

Just how supported and standard is this? Chrome seems to use it
for something else:

http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal


I was told by Google that they are phasing this out (this may already 
have happened), and then will fix 
http://code.google.com/p/chromium/issues/detail?id=109012.


Not that it *is* implemented in Firefox 14, shipping next week: 
https://bugzilla.mozilla.org/show_bug.cgi?id=714302.


Best regards, Julian

Re: Time for Apache httpd 2.4.3 ??

[Julian Reschke]

On 2012-07-10 16:16, Jim Jagielski wrote:

I'd like to propose an Apache httpd 2.4.3 release RSN... I'll RM.


Would be awesome to get 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53292 into both 
trunk and 2.4.*...


Best regards, Julian

build problems

[Julian Reschke]

Hi there,

I was trying to build trunk, and encountered the following problem 
(after running autoconf; assuming that was right):



$ ./configure --prefix=/srv
./configure: line 2909: syntax error near unexpected token `Apache,'
./configure: line 2909: `APR_ENABLE_LAYOUT(Apache, errordir iconsdir htdocsdir 
cgidir)'


This was under Cygwin/Win7, but a colleague tried under OSX and Linux 
and got similar results.


Help appreciated,

Julian

Re: build problems

[Julian Reschke]

On 2012-07-05 14:17, Plüm, Rüdiger, Vodafone Group wrote:

You don't need to run  autoconf. If you want to rebuild configure please run 
buildconf in the same directory as configure.
...


I don't want to *re*build configure, I just want to *build* it. It's not 
in SVN, after all.


So what are the correct steps, starting with a fresh checkout?

Best regards, Julian

Re: build problems

[Julian Reschke]

On 2012-07-05 14:57, Plüm, Rüdiger, Vodafone Group wrote:

Then you need to execute buildconf. It is mandatory in this case.

Regards

Rüdiger
...


I see; thanks for the help!

Re: TRACE still enabled by default

[Julian Reschke]

On 2012-03-20 20:04, Stefan Fritsch wrote:

...
It can also compound security issues in webapps. In general, one can

  ^^^

How so? When you say webapps, are you referring to something not 
running via script/XHR?


Best regards, Julian

Re: ACL changes in mod_dav

[Julian Reschke]

On 22.02.2010 19:25, Brian J. France wrote:


On Feb 20, 2010, at 11:23 PM,markus.l...@dlr.de  markus.l...@dlr.de  wrote:

I have added ACL features to the mod_dav module. Could you tell me the
correct way to get this changes reviewed and into to official
mod_dav-source?



Did you use any of the public available mod_dav_acl[1] code?

I have been splitting up the mod_dav_acl patch into little patches and 
submitting them.  I sent the last supporting patch today and the last thing 
that is missing from trunk is the acl hooks structure from the patch and of 
course the mod_dav_acl module it self.  All this code is in trunk and could be 
back ported down the road to 2.2 as it has all been done in a binary compatible 
way.

Brian


Brian,

out of curiosity: did you find any problems with RFC 3744? I'm 
maintaining an issues list 
(http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-issues.html), 
and plan to revise that spec at some future date (maybe when HTTPbis is 
done), so it would be extremely useful to get more feedback...


Best regards, Julian

Re: mod_dav inconsistent behaviour for GET requests

[Julian Reschke]

Stefan Fritsch wrote:

Hi,

mod_dav doesn't handle GET requests in a consistent way: If a repos 
provider has handle_get == 1, mod_dav will handle GET requests by 
itself. This means no other handler will get a chance to interpret the 
file as script or SSI. On the other hand, if the repos provider has 
handle_get == 0, mod_dav will do nothing and another handler like 
mod_php or mod_include may handle scripts, causing the output of the 
script execution to be sent to the client instead of the script 
source.

...


Lesson: don't serve the script's output and the script itself from the 
same URI.


And if you really really have to, consider using the MS extension 
request header Translate.


BR, Julian

Re: DAV Option Patch

[Julian Reschke]

Brian J. France wrote:

...
There is one draw back to this patch in that there could be duplicated 
values in the headers.  Both mod_dav_acl and mod_caldav want to add the 
REPORT in the Allow header, so it would show up twice in the list.  I am 
not sure if this is a major problem, but wanted to make a note of it.

...


It shouldn't be a problem, but on the other hand: is there any 
particular reason for the new code not to enforce each value is only 
reported once?


BR, Julian

Re: WebDav MOVE/COPY between servers

[Julian Reschke]

Rafa%u0142 wrote:

Hello!

I've done first part of the job - there is now a FETCH method that works 
in that way:


FETCH /destination/path HTTP/1.1
Source: http://webdav.example.com/webdav-resource-to-fetch
...


I'm not sure it's a good idea to define a new method for that.

If people *really* think that this functionality is needed, than 
re-using COPY seems to make more sense (we could define a new variant 
that takes a Source header instead of the currently mandatory 
Destination header).


 ...

BR, Julian

DefaultType None directive

[Julian Reschke]

Hi,

looking at https://issues.apache.org/bugzilla/show_bug.cgi?id=13986#c64:


  --- Comment  #64 From Phil Ringnalda  2008-07-03 00:07:23 PST  [reply] 
---

While I don't have any real expectation of action coming from a comment on a
resolved bug, I still want to mention that the fix for this bug did not fix
this bug: it made it _possible_ to remove default MIME-type while ignoring
the part of comment 55 about a) remove DefaultType from the standard
httpd.conf.in file, which still combines a text/plain default with simply
awful advice about using text/plain If your server contains mostly ... HTML
documents.


It seems Phil is correct in that this issue shouldn't be closed until 
the default httpd.conf also is changed.


Furthermore, has backporting been considered?

BR, Julian

Re: WebDav MOVE/COPY between servers

[Julian Reschke]

Rafa%u0142 wrote:

Hello.
  My name is Rafał Malinowski. I want (really, I have to) add one feature 
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.


Why? Do you have any clients that would use it?

  As I looked into code and into specification such thing is allowed, but 
not implemented yet. I hope I'll have it done with some help from this 
list, and I hope it will not take more than one month of work ;)

  If someone wants to help me/have some good advice, I would appreciate it.
...


How do you intend to solve the authentication problem?

BR, Julian

Re: WebDav MOVE/COPY between servers

[Julian Reschke]

Rafa%u0142 wrote:

Dnia 3-07-2008 o godz. 13:22 Julian Reschke napisał(a):

Rafał wrote:

Hello.
  My name is Rafał Malinowski. I want (really, I have to) add one feature
to WebDav: support for MOVE/COPY with remote servers as 'Destination'.

Why? Do you have any clients that would use it?


I will use telnet. After the server work is done I will extend existing 
Vinetoolkit Webdav client to support this.



How do you intend to solve the authentication problem?


SAML2 tokens over GSS with delegations.


OK, seems you know what you do :-)

BR, Julian

Re: Expect: non-100 messages

[Julian Reschke]

Charles Fry wrote:

Greetings Apache Developers,

We have implemented an Apache module which needs to process incoming
Expect headers for non-100-expectations. The version of
server/protocol.c currently in the trunk has a hard-coded Expect
header check that handles Expect: 100-continue, but fails on any
other expectation. It would seem consistent with the general
modularization of the the httpd server to be able to allow
non-100-expectations to be accepted and processed when desired. We
would be glad to help make the code modifications to accommodate such
functionality, if that would facilitate making such a change. Let us
know how to best proceed to enable non-100-expectations in httpd.

 ...

Hm.

We talked about things like that in the WebDAV WG years ago.

The problem with Expect is that it's hop-to-hop... 
(http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.20). So 
how do you deploy new expectation codes when you need to pass through 
proxies???


BR, Julian

Re: Expect: non-100 messages

[Julian Reschke]

Charles Fry wrote:

Well, I guess that partly depends on how deployed proxies deal with
unrecognized Expect headers. Do any of you have any practical
knowledge of how current proxies deal with new Expect headers? There
does at least seem to be a precedent with WebDAV sending 102 status
codes (though I know nothing first-hand about this, including how well
it is received by proxies).


a) There's no Expect code related to status 102.

b) RFC4918 removed status 102 anyway, as nobody was implementing it.

I agree it would be nice to know what proxies actually do; maybe they do 
not do what RFC2616 requires, and thus Expect could indeed be made 
useful :-)


See 
http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0043.html 
(I'd propose to continue the conversation over there).



The HTTP spec does specify that the hop-to-hop decision MUST be made
at a protocol level
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3). In
other words, at least in the case of the Expect 100, a 417 is only
injected by a proxy with a known next-hop 1.0 or lower server. Similar
behavior with new Expect headers would be just fine in our case.


But that's a special case for 100-continue, which is a MUST level 
feature for all HTTP/1.1 components anyway.


I think it's clear that a proxy that sees Expect: foobar will have to 
immediately fail with status 417 if it doesn't know what foobar means.


BR, Julian

Re: new mime type needed?

[Julian Reschke]

Guenter Knauf wrote:

Hi,
just another compression utility is going to become very popular:
http://www.7-zip.org/
and there's also a commandline for Unix / Win32:
http://sourceforge.net/projects/p7zip/

maybe we should add the .7z extension to the httpd mime.types file?
perhaps something like:

application/x-7-zip 7z


Guen.


...pointing out the obvious: the mime type should be registered with 
IANA first.


BR, Julian

Re: thoughts on ETags and mod_dav

[Julian Reschke]

Chris Darroch wrote:

Hi --


1) Per #38034, it appears that ap_meets_conditions() treats * incorrectly.


   More precisely, I should say that ap_meets_conditions() isn't designed
to support the NULL resources of RFC 2518 (WebDAV).  I'm certainly no
expert on these issues, so guidance is welcome.


Clarifying: RFC2518 doesn't invent NULL resources, it just assigns a 
term to them.



   RFC 2616 section 14.24 (and 14.26 is similar) says, If the request
would, without the If-Match header field, result in anything other than a
2xx or 412 status, then the If-Match header MUST be ignored.  Thus in
the typical case, if a resource doesn't exist, 404 should be returned,
so ap_meets_conditions() doesn't need to handle this case at all.


Unless it is a method that can be applied to a NULL resource, such as 
PUT, PATCH (?), MKCOL, LOCK...



   RFC 2518 introduces lock-null resources for use with certain
methods such as LOCK, PUT, and UNLOCK.  (RFC 4918, it seems, deprecates
lock-null resources in favour of locked empty resources.)  For these
particular methods and resources, other language from RFC 2616's
section 14.24 (again, 14.26 is similar) comes into play, specifically,
If none of the entity tags match, or if '*' is given and no current entity
exists, the server MUST NOT perform the requested method, and MUST return a
412 (Precondition Failed) response.


That's correct, but see above -- it's not restricted to lock-null 
resources, and also not to WebDAV methods.



...


Best regards, Julian

Re: ETag and Content-Encoding

[Julian Reschke]

Henrik Nordstrom wrote:

On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:


The issue here is that mod_dav_svn generates an ETag (based off rev
num and path) and that ETag can be later used to check for conditional
requests.  But, if mod_deflate always strips a 'special' tag from the
ETag (per Henrik),


That was only a suggestion on how you may work around your somewhat
limited conditional processing capabilities wrt filters like
mod_deflate, but I think it's probably the cleanest approach considering
the requirements of If-Match and modifying methods (PUT, DELETE,
PROPATCH etc). In that construct the tag added to the ETag by
mod_deflate (or another entity transforming filter) needs to be
sufficiently unique that it is not likely to be seen in the original
ETag value.
...


Two cents -- no three cents :-):

#1) I agree with Henrik's analysis.

#2) If Content-Encoding is implemented through a separate module, it 
will have to rewrite both outgoing and incoming etags; note that this 
includes the If-* headers from RFC2616 and the If header defined in 
RFC4918 (obsoleting RFC2518).


#3) If just appending -gzip doesn't provide sufficient uniqueness, the 
 implementation may want to *always* append a token (such as 
-identity), even when no compression occurred.


Best regards, Julian

Re: updated mime.types

[Julian Reschke]

Roy T. Fielding wrote:

Please check out the updated mime.types file and, if possible, see
if it breaks anything on a real site.

http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

Technically, it is docs, but I am blurry-eyed at the moment and need
to do *something* for my wedding anniversary today.  If it seems okay,
we should backport it to all versions prior to the release.


Please update

  application/davmount+xml

to

  application/davmount+xmldavmount

(http://tools.ietf.org/html/rfc4709#section-6.1).

Thanks, Julian

Re: Reverse proxy mode and DAV protocol

[Julian Reschke]

Eygene Ryabinkin schrieb:

Julian, good day.

Tue, Apr 03, 2007 at 06:52:59PM +0200, Julian Reschke wrote:

Eygene Ryabinkin schrieb:

Good day!
Sorry for rather long letter, but this is the summary from numerous
discuissions and I really tried to make it short.
...

Hi.

RFC2518bis allows the Destination header to be just an absolute path for 
exactly that reason (see 
http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#destination-header). 


Pardon for my stupideness, but what 'that reason' you are talking
about? The previous letter was rather long and I fail to identify
the exact point you're commenting. Could you, please, elaborate
a bit?


Sorry.

What I meant by reason was the fact that the Destination header (and 
some aspects of the If header) require absolute URIs, which is 
problematic when there's a reverse proxy in the transmission path. All 
the issues around to rewrite or not to rewrite headers go away once 
these headers use absolute paths (well, as long as the reverse proxy 
doesn't also rewrite paths, but I would claim that this is nearly 
impossible to get right with WebDAV).



So this is really one of the few things why RFC2518bis support would be useful
in practice (if clients start to take advantage of it).


But even if the 'Destination' is just the absolute path, then in
the reversy proxying from the http://frontend/dir-one to the
http://backend/some-long-path/dir-two we will still need to rewrite
that absolute path. It is not very uncommon to see the reverse


Right (see above). But if you also rewrite paths, you will also need to 
rewrite all multistatus response bodies. Thus is why I assumed nobody is 
traing that.



proxying for the different absolute paths on the frontend and backend
servers: I've seen some that were due to some software weirdness
(for example, two proxied Wiki instances that require the /wiki
path to be present in both of them) or some legacy configuration
that can not be readily changed due to the poor design. Am I missing
some point?


I haven't seen reverse proxying with path rewriting working for WebDAV 
so far. My assumption was that the easy variant (host/port) is already 
hard enough, and the intent of those changes in RFC2518bis is to make at 
least this case simpler.


Best regards, Julian

Re: Reverse proxy mode and DAV protocol

[Julian Reschke]

Eygene Ryabinkin schrieb:

Julian,

Wed, Apr 04, 2007 at 01:12:54PM +0200, Julian Reschke wrote:

Pardon for my stupideness, but what 'that reason' you are talking
about? The previous letter was rather long and I fail to identify
the exact point you're commenting. Could you, please, elaborate
a bit?

Sorry.

What I meant by reason was the fact that the Destination header (and some 
aspects of the If header) require absolute URIs, which is problematic when 
there's a reverse proxy in the transmission path. All the issues around to 
rewrite or not to rewrite headers go away once these headers use absolute paths
(well, as long as the reverse proxy doesn't also rewrite paths, but I would 
claim that this is nearly impossible to get right with WebDAV).


Ahh, OK, thanks for the clarification. I had just tried to do path
rewriting and I see that things are bad: I am using Git over HTTP
and it fails badly with the path rewriting. May be will try to
understand why, but I am not sure.

So, your point is that Apache should make no attempts to rewrite
the 'Destination' header for DAV and clients should use absolute
paths for DAV. Or we still need 'Destination' rewriting? In the
reverse proxy mode, I mean.

Thank you!


I'd say Path rewriting is very hard, host rewriting is possible.

With RFC2518bis, clients can use absolute paths in some places where 
before an absolute URI was required. This makes host rewriting much 
easier, but of course that change needs to get deployed.


1) Servers, such as Apache/moddav should start supporting absolute paths 
in the Destination and If headers ASAP. That's a backwards 
compatible change and should be easy to deploy. Unfortunately, there's 
no simple way to check whether a server allows path notation, except by 
explicitly checking for DAV compliance level 3 
(http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#rfc.section.18.3).


2) Clients should use absolute paths as soon as they see that the remote 
server allows this.


Of course all of this is of little value until widely deployed 
servers/clients start using it.


Best regards, Julian

Re: Reverse proxy mode and DAV protocol

[Julian Reschke]

Eygene Ryabinkin schrieb:

Julian,

Wed, Apr 04, 2007 at 03:22:53PM +0200, Julian Reschke wrote:

So, your point is that Apache should make no attempts to rewrite
the 'Destination' header for DAV and clients should use absolute
paths for DAV. Or we still need 'Destination' rewriting? In the
reverse proxy mode, I mean.
Thank you!

I'd say Path rewriting is very hard, host rewriting is possible.


So, if Apache will be able to do the rewriting in its modules, then
it should try. OK, thank you.


1) Servers, such as Apache/moddav should start supporting absolute paths in the
Destination and If headers ASAP.


Again, talking about the current situation when URI are absolute:
do you think that 'If' header automatical rewriting is possible and
viable for the Apache's modules? I see no technical problems in
such rewriting, but may be I am missing something.

Thank you!


If header rewriting should be possible, as long as the code doing the 
rewriting does the rewriting carefully (for instance, scanning for 
.* will probably not be good enough...).


Best regards, Julian

Re: Reverse proxy mode and DAV protocol

[Julian Reschke]

Eygene Ryabinkin schrieb:

Good day!

Sorry for rather long letter, but this is the summary from numerous
discuissions and I really tried to make it short.
...


Hi.

RFC2518bis allows the Destination header to be just an absolute path for 
exactly that reason (see 
http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#destination-header). 
So this is really one of the few things why RFC2518bis support would be 
useful in practice (if clients start to take advantage of it).


Best regards, Julian

Re: 4GB File size limit

[Julian Reschke]

[EMAIL PROTECTED] wrote:
Hmmm, I wonder if the problem is the browser? I've tried downloading that file 
with Opera and IE and on both browsers, it says the file is 75,673,600 bytes, 
which is wrong.
So does Firefox. However, Live HTTP Headers shows:
GET /pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso HTTP/1.1
Host: ftp.heanet.ie
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) 
Gecko/20041107 Firefox/1.0
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Date: Mon, 03 Jan 2005 22:58:29 GMT
Server: Apache/2.0.52 (Unix)
Last-Modified: Thu, 20 May 2004 13:48:37 GMT
Etag: 8b000d59-482b000-6e847740
Accept-Ranges: bytes
Content-Length: 4370640896
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream
4370640896 is 0x10482B000 and 75673600 is 0x482B000, so this is almost 
certainly a 32-bit integer overflow. Somebody should open an issue on 
the Mozilla bug tracker

My largefile woes might be because of shortcomings in the browser, rather than 
in apache.
Seems so.
Regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: 4GB File size limit

[Julian Reschke]

Julian Reschke wrote:
4370640896 is 0x10482B000 and 75673600 is 0x482B000, so this is almost 
certainly a 32-bit integer overflow. Somebody should open an issue on 
the Mozilla bug tracker
https://bugzilla.mozilla.org/show_bug.cgi?id=276927
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: Any plans for RFC3744

[Julian Reschke]

Bennett, Tony - CNF wrote:
...
Also...One question I had about 3744... 
the RFC says in the Introduction: 

   ...The operations you can perform are determined by a
   single access control list (ACL) associated with a resource.
This seems to mirror UNIX's file mode...
...however, in UNIX if a parent directory prevents access, then 
even if the file's mode allows access, the file access is prevented.

The RFC seems to say to me, the resource's mode is the single
determining
factor.  Its parent collection's mode is of no consequence.  

Am I reading this right???
Yes and no. The access rights are modeled on the resource and never are 
implicitly inherited. You *may* use inherited privileges, though, see 
http://greenbytes.de/tech/webdav/rfc3744.html#PROPERTY_inherited-acl-set), 
but that probably wouldn't work well here if you'd have a backend that 
allows multiple collection bindings (ie. multiple hard links to 
folders), so the same resource (file) would appear in multiple WebDAV 
collections (folders).

On the other hand, there's nothing that prevents you from requiring a 
special directory access privilege on the collection identified by the 
parent of the request URI in addition to the standard DAV:* privileges 
on the leaf node.

Anyway, for questions about the spec itself you may want to address 
mailto:[EMAIL PROTECTED] (I'm not sure all of the authors are subscribing 
this list).

Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: mod_proxy distinguish cookies?

[Julian Reschke]

FYI: I recently had a long exchange with Microsoft's support regarding 
the Vary header, and the outcome was that they have at least 
*documented* their RFC2616 compliance issue:

http://support.microsoft.com/default.aspx?scid=kb;en-us;824847

Best regards, Julian

--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: cvs commit: httpd-2.0 STATUS

[Julian Reschke]

Joe Orton wrote:

On Sat, Jan 24, 2004 at 12:48:33AM +0100, André Malo wrote:

* Greg Stein [EMAIL PROTECTED] wrote:


On Fri, Jan 23, 2004 at 11:28:28PM +0100, André Malo wrote:

Hmm, and then? I'd see it as a workaround for buggy clients like the
redirect-carefully variable.
It's a matter of degree. Just how many clients are broken, and what
percentage of traffic do they represent? The redirect-carefully was put in
because of a great many, popular clients were borken.
Dunno ;-) How many clients are we talking about?
Redirect-Carefully IMHO affects all Microsoft Webfolder clients. Maybe 
this needs to be added to the (webfolder) issues list?

Julian Reschke's bug-tracker lists the versions of the MS clients this
is known to affect: (that doesn't really answer the question, I know)
http://greenbytes.de/tech/webdav/webfolder-client-list.html#issue-hashmark-escaping

As I understand it, the clients only screw up when hash is the first
character of the last path segment: is that right Julian?  I'd consider
it a relatively obscure issue, it's not worth putting a lot of effort
into other than making sure the requests are rejected.
If the hashmark is the first character of a path segment, buggy servers 
will apply the request to the parent collection instead of just 
rejecting the request (it's not a valid request according to RFC2616). 
This is of course a desaster for DELETE.

On the other hand, if the hashmark isn't the first character, the 
request may get applied to the resource identified by the path segment 
truncated at the #. So, you may want to delete a%23b, but what get's 
deleted is a. Still a major problem.

So there are (were) two issues: a client (Webfolder) that didn't escape 
the hashmark (only a few releases, and I think this issue is resolved in 
later clients), and a server that doesn't (didn't?) reject invalid requests.

Hope this helps.

Julian

P.S.: The issue list mentioned above depends on people contributing 
empirical data. Hint, hint. :-)

--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

httpd 2.1 project plan vs LINK method

[Julian Reschke]

From...:

http://httpd.apache.org/dev/project-plan.html

- Implementation of the LINK Method

Can anybody tell me what this is?

Regards, Julian

--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: httpd 2.1 project plan vs LINK method

[Julian Reschke]

Roy T. Fielding wrote:

On Wednesday, January 14, 2004, at 01:04  PM, Julian Reschke wrote:

From...:

http://httpd.apache.org/dev/project-plan.html

- Implementation of the LINK Method

Can anybody tell me what this is?


See RFC 2068, section 19.6.1.2 and 19.6.2.4
(you might want to look at the description of PATCH as well).
Ah! Should have thought about that myself :-)

Just ignore the project-plan page -- it hasn't been updated since 1996.
Thanks, Julian

--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760