[JCR-3228] WebDav/DavEx remoting throws workspace mismatch exceptions when running on port 80

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.2.13, 2.4.4, 2.6.2, 2.7
• Fix Version/s: 2.4.5, 2.6.3, 2.7.1
• Component/s: jackrabbit-spi2dav, jackrabbit-webdav
• Assignee: Julian Reschke
• Reporter: Timothee Maret
• Created: 07/Feb/12 10:04
• Updated: 16/Sep/13 07:59
• Resolved: 23/Jul/13 11:53

Description

When running on port 80, the webdav remoting shows unexpected behavior such as listing incomplete folder content.
Moreover the following exception is thrown:

The exception I get: java.lang.IllegalArgumentException: Workspace missmatch.
[org.apache.jackrabbit.spi2dav.IdURICache.add(IdURICache.java:60),
org.apache.jackrabbit.spi2dav.URIResolverImpl.getItemUri(URIResolverImpl.java:129),
org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.getItemUri(RepositoryServiceImpl.java:391),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:149),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:138),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getItemInfos(RepositoryServiceImpl.java:265),
org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:93),
org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:97),
org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.doResolve(NodeEntryImpl.java:990),
org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.resolve(HierarchyEntryImpl.java:133),
org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.getItemState(HierarchyEntryImpl.java:252),
org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getItemState(NodeEntryImpl.java:71),
org.apache.jackrabbit.jcr2spi.ItemManagerImpl.getItem(ItemManagerImpl.java:199),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.prefetchNext(LazyItemIterator.java:138),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.next(LazyItemIterator.java:251),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.nextNode(LazyItemIterator.java:154),
com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:121),
com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:43),
com.adobe.drive.model.internal.synchronization.AssetSynchronizer.execute(AssetSynchronizer.java:432),
com.adobe.drive.model.internal.synchronization.AssetSynchronizer.synchronizeStructure(AssetSynchronizer.java:352),
com.adobe.drive.internal.data.manager.DataManager.getChildren(DataManager.java:2602),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:98),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:73),
com.adobe.drive.model.context.Context.run(Context.java:88),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:126),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:50),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:125),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:119),
com.adobe.drive.data.internal.persistence.PersistenceRunner.run(PersistenceRunner.java:119),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall.execute(VersionCueCall.java:134),
com.adobe.drive.internal.biz.versioncue.service.VersionCueService.getChildren(VersionCueService.java:269),
com.adobe.drive.ncomm.versioncue.GetChildren.handle(GetChildren.java:59),
com.adobe.drive.ncomm.versioncue.VersionCueRequestHandler$1.run(VersionCueRequestHandler.java:185),
com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:270),
com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:286),
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886),
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908),
java.lang.Thread.run(Thread.java:680)]

I have tracked this issue and actually the HTTP "Host" header which is used to identify the webdav server does not contain the port (only the host) when running on port 80, whereas it contains the <host>:<port> when running on any other port.

Issue Links

• is duplicated by: JCR-3510 WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 443.
• is related to: JCR-3625 make port number for webdav integration tests configurable
• relates to: JCR-3510 WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 443.