[jira] [Commented] (LANG-1543) [JSON string for maps] ToStringBuilder.reflectionToString doesnt render nested maps correctly.
[
https://issues.apache.org/jira/browse/LANG-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117470#comment-17117470
]
Swaraj Pal commented on LANG-1543:
--
[~kinow] LANG-1542 is related to Collection of Enumerations only, however in
this issue indicated towards general Map handling.
> [JSON string for maps] ToStringBuilder.reflectionToString doesnt render
> nested maps correctly.
> --
>
> Key: LANG-1543
> URL: https://issues.apache.org/jira/browse/LANG-1543
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.10
>Reporter: Swaraj Pal
>Priority: Major
>
> Nested Maps are not converted correctly as JSON using
> ToStringBuilder.reflectToString commons-lang3:3.10 . Please find below the
> example to reproduce:-
> Class:
> {code:java}
> public class Student {
> private String name;
> private Map education;
> //getters and setters...
> public String toString() {
> return ToStringBuilder.reflectionToString(this,
> ToStringStyle.JSON_STYLE);
> }}
> {code}
>
> Driver test:
> {code:java}
> Student p = new Student();
> p.setName("como");
>
> Map educationMap = new HashMap();
> educationMap.put("primary", "school");
> educationMap.put("graduation", "B.S.");
>
> p.setEducation(educationMap);
>
> System.out.println(p.toString());
> {code}
> The toString() prints
> {code:java}
> {"education":{graduation=B.S., primary=school},"name":"como"}
> {code}
> but I expect as JSON it should print as below (with proper key,value pairs as
> field names and values)
> {code:java}
> {"education":{"graduation": "B.S.", "primary":"school"},"name":"como"}
> {code}
> Suggested fix:
> I can create a Pull request for this issue handling Maps appending logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-email] XenoAmess opened a new pull request #16: fix code smells
XenoAmess opened a new pull request #16: URL: https://github.com/apache/commons-email/pull/16 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess commented on pull request #16: fix code smells
XenoAmess commented on pull request #16: URL: https://github.com/apache/commons-email/pull/16#issuecomment-634568042 advice: well I still think some functions duplicated in EmailUtils from commons-lang shall be replaced by what from commons-lang...but that is another story. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (FILEUPLOAD-274) File Upload fails to recognize RFC 5987-compliant filename
[ https://issues.apache.org/jira/browse/FILEUPLOAD-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-274. Fix Version/s: 2.0 Assignee: Jochen Wiedmann Resolution: Fixed > File Upload fails to recognize RFC 5987-compliant filename > -- > > Key: FILEUPLOAD-274 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-274 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vsevolod Poletaev >Assignee: Jochen Wiedmann >Priority: Major > Fix For: 2.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > I think there is incorrect behaviour in getFileName() method of > FileUploadBase class, as it ignores RFC-5987-compliant filename* parameter, > and then findNextItem() method incorrectly treats this part of request as > form filed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-291) commons-fileupload-1.3.3.jar is missing reference to javax/portlet/ActionRequest to support Java 11
[ https://issues.apache.org/jira/browse/FILEUPLOAD-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117627#comment-17117627 ] Jochen Wiedmann commented on FILEUPLOAD-291: What exactly would you like to see changed? > commons-fileupload-1.3.3.jar is missing reference to > javax/portlet/ActionRequest to support Java 11 > --- > > Key: FILEUPLOAD-291 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-291 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.3 >Reporter: Bonda Pavan Kumar >Priority: Critical > > We are using apache *commons-fileupload-1.3.3.jar* for internal requirements > and this is having potential issues with respect to Java 11 support. On > preliminary analysis, identified that this jar (1.3.3 version) is having a > missing reference to this class *javax/portlet/ActionRequest*. > Can this be prioritized at the earliest? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-287) Multipart/mixed parts not handled correctly
[
https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117631#comment-17117631
]
Jochen Wiedmann commented on FILEUPLOAD-287:
Assuming that you are right: There's nothing, which prevents you from sending a
content-disposition header anyways, isn't it?
Apart from that: Whaot would you expect getFieldName() to do without such a
header?
> Multipart/mixed parts not handled correctly
> ---
>
> Key: FILEUPLOAD-287
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-287
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.3
>Reporter: Etienne Dethoor
>Priority: Critical
>
> If i submit a request with global header
> {{Content-Type="multipart/mixed;boundary="uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f";charset=UTF-8"}}
> data to a servlet with :
> {code:xml}
> --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID: myFile
> My_Content_Here
> --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f
> Content-Type: application/xml
> Content-Transfer-Encoding: binary
> Content-ID: myOtherFileHere
> M_Other_Content_Here
> {code}
> The differents parts are not recognized because of
> {{FileUploadBase.getFieldName()}} method who want a {{Content-Disposition}}
> header for each part of the request.
> The [rfc|https://tools.ietf.org/html/rfc7578#section-4.2] specified that this
> header is mandatory for the {{multipart/form-data}} content-type.
> For the {{multipart/mixed}}, if i well understand, the rfc doesn't say this
> header is mandatory for each parts of the request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-193) FileNotFoundException thrown by DiskFileItem.write
[
https://issues.apache.org/jira/browse/FILEUPLOAD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved FILEUPLOAD-193.
Fix Version/s: 2.0
Resolution: Fixed
> FileNotFoundException thrown by DiskFileItem.write
> --
>
> Key: FILEUPLOAD-193
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-193
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2.2
> Environment: Ubuntu 10.10
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
>Reporter: Dan Washusen
>Priority: Critical
> Fix For: 2.0
>
>
> Under certain conditions the DiskFileItem.write throws a FileNotFound
> exception. It seems to be when outputFile.renameTo(file) fails.
> {code}java.io.FileNotFoundException:
> /tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
> (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
> at upload.UploadController.handle(UploadController.java:90)
> ...{code}
> I can't see any obvious reason why the source file (outputFile) wouldn't
> exist...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-298) Don't use temp directory by default for storing uploaded files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-298. Resolution: Won't Fix Rejected. There is no reasonable scenario, when the users home directory would be a better default. Apart from that, nothing prevents you to use setRepository(), or fix the value of java.io.tmpdir. > Don't use temp directory by default for storing uploaded files > -- > > Key: FILEUPLOAD-298 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-298 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: Artem Smotrakov >Priority: Major > Attachments: use_app_work_directory_v1.patch > > > By default, DiskFileItem stores uploaded files in the directory defined by > java.io.tmpdir system property which creates a weakness described in > CVE-2013-0248. > [https://nvd.nist.gov/vuln/detail/CVE-2013-0248] > The patch for CVE-2013-0248 just updates the docs with a note that the > setRepository() method must be used in case of untrusted environment. > [https://github.com/apache/commons-fileupload/commit/f874563307c1159ac634df67509d9859bca6ddb9] > I am wondering if it would be better to use user.dir or user.home system > properties instead of java.io.tmpdir: > * Normally only the user which started the application can write to user.home > * It seems to be more likely that user.dir is not publicly writable > I am attaching a draft patch which updates DiskFileItem to use a subdirectory > under user.dir although user.home looks to be a better option from security > perspective. > If no objections, I will finalize the patch and create a pull request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-286) default charset override
[ https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-286. Fix Version/s: 2.0 Resolution: Fixed > default charset override > > > Key: FILEUPLOAD-286 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: maxxedev >Priority: Major > Fix For: 2.0 > > > If charset is not specified, ISO charset is chosen as default. > Allow that default charset to be overridden. > useful in cases where form-data is utf-8 encoded but not encoding is not > explicitly specified -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-297) Default maximum sizes for requests and files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-297. Resolution: Won't Fix Rejected for reasons of upwards compatibility. > Default maximum sizes for requests and files > > > Key: FILEUPLOAD-297 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-297 > Project: Commons FileUpload > Issue Type: Improvement >Reporter: Artem Smotrakov >Assignee: Jochen Wiedmann >Priority: Major > Attachments: default_upload_size_limits_v1.patch > > > Currently FileUpload allows setting the maximum allowed size of a complete > request and the maximum allowed size of a file to be uploaded. However the > library doesn't set any default limitations. Introducing default values may > be a little defense-in-depth measure to reduce a risk of (D)DoS attacks for > applications which forgot to set such limits. > Here is how other libraries/servers set such default values: > # nginx sets the maximum allowed size of the client request body to 1MB > ## > [http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size] > # By default, the IIS 7 upload limit is 30MB > ## [https://docs.microsoft.com/en-us/windows/desktop/bits/upload-limits] > # PHP sets max size of post data allowed to 8MB. PHP also sets the maximum > size of an uploaded file to 2MB > ## [https://www.php.net/manual/en/ini.core.php#ini.post-max-size] > ## [https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize] > # Spring Boot specifies the maximum size permitted for uploaded files. The > default is 1MB. It also specifies the maximum size allowed for > multipart/form-data requests. The default is 10MB. > ## > [https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/autoconfigure/web/servlet/MultipartProperties.html] > As you can see, default values look pretty different. I am attaching a patch > which sets the maximum file size to 2MB and the maximum size of a request to > 10MB. Adding such limits by default introduces a risk that some applications > may break, so maybe the numbers should be higher. Please let me know if such > an update is okay, and I'll create a pull request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FILEUPLOAD-265) .MultipartStream$MalformedStreamException: Stream ended unexpectedly
[ https://issues.apache.org/jira/browse/FILEUPLOAD-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-265. Resolution: Incomplete Without a protocol of the incoming byte stream, or another means to reproduce this, there is no chance to work on that. > .MultipartStream$MalformedStreamException: Stream ended unexpectedly > > > Key: FILEUPLOAD-265 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-265 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.1 > Environment: httpclient >Reporter: zhumingu >Priority: Major > Labels: Stream, ended, unexpectedly > > When uploading files using the browser,it does not happen.But when submission > using tools with 'multipart/form-data',for example httpclient,advanced rest > client and so on, > Only submit a text field, file field is empty, it will report the following > exception: > org.apache.commons.fileupload.MultipartStream$MalformedStreamException: > Stream ended unexpectedly > at > org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:540) > at > org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:1038) > at > org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:1003) > at > org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310) > at > org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:334) > at > org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115) > > A simple analysis that, when using the browser, file is not selected, the > default browser will join the empty data file-part. > But the use of tools such as httpclient, when the file is empty, it do not > contain the documents data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-285) MultipartStream API constructor has internal class
[ https://issues.apache.org/jira/browse/FILEUPLOAD-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117640#comment-17117640 ] Jochen Wiedmann commented on FILEUPLOAD-285: How about a pull request, or proposed patch? > MultipartStream API constructor has internal class > -- > > Key: FILEUPLOAD-285 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-285 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Obidul >Priority: Major > > The last argument of the constructor is internal class (ProgressNotifier). > How to use notifier in the constructor. > MultipartStream(InputStream input, byte[] boundary, int bufSize, > MultipartStream.ProgressNotifier pNotifier) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r closed pull request #77: GEOMETRY-94: PlaneConvexSubset implementations
darkma773r closed pull request #77: URL: https://github.com/apache/commons-geometry/pull/77 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on pull request #77: GEOMETRY-94: PlaneConvexSubset implementations
darkma773r commented on pull request #77: URL: https://github.com/apache/commons-geometry/pull/77#issuecomment-634599684 Merged in commit ed41804dc3f8273e483ddfabd331732e1ae2c550 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GEOMETRY-94) ConvexSubPlane Subclasses
[
https://issues.apache.org/jira/browse/GEOMETRY-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-94.
---
Resolution: Done
> ConvexSubPlane Subclasses
> -
>
> Key: GEOMETRY-94
> URL: https://issues.apache.org/jira/browse/GEOMETRY-94
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
> Fix For: 1.0
>
>
> There should be specific subclasses of {{ConvexSubPlane}} to allow for
> optimization and ease of use.
> - {{OpenConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane that is open on a least one side and has infinite size
> - {{ClosedConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane with finite size; the 2D subspace is a polygon
> - {{Triangle3D}} - extends {{ClosedConvexSubPlane}}; represents a triangle
> in 3D space; most 3D models are or can easily be represented with triangles
> so it would be good to have a dedicated class for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEOMETRY-94) ConvexSubPlane Subclasses
[
https://issues.apache.org/jira/browse/GEOMETRY-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed GEOMETRY-94.
-
Assignee: Matt Juntunen
> ConvexSubPlane Subclasses
> -
>
> Key: GEOMETRY-94
> URL: https://issues.apache.org/jira/browse/GEOMETRY-94
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Major
> Labels: beta1
> Fix For: 1.0
>
>
> There should be specific subclasses of {{ConvexSubPlane}} to allow for
> optimization and ease of use.
> - {{OpenConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane that is open on a least one side and has infinite size
> - {{ClosedConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane with finite size; the 2D subspace is a polygon
> - {{Triangle3D}} - extends {{ClosedConvexSubPlane}}; represents a triangle
> in 3D space; most 3D models are or can easily be represented with triangles
> so it would be good to have a dedicated class for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-94) ConvexSubPlane Subclasses
[
https://issues.apache.org/jira/browse/GEOMETRY-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117678#comment-17117678
]
Matt Juntunen commented on GEOMETRY-94:
---
Merged in commit ed41804dc3f8273e483ddfabd331732e1ae2c550.
> ConvexSubPlane Subclasses
> -
>
> Key: GEOMETRY-94
> URL: https://issues.apache.org/jira/browse/GEOMETRY-94
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
> Fix For: 1.0
>
>
> There should be specific subclasses of {{ConvexSubPlane}} to allow for
> optimization and ease of use.
> - {{OpenConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane that is open on a least one side and has infinite size
> - {{ClosedConvexSubPlane}} - extends {{ConvexSubPlane}}; represents a convex
> subplane with finite size; the 2D subspace is a polygon
> - {{Triangle3D}} - extends {{ClosedConvexSubPlane}}; represents a triangle
> in 3D space; most 3D models are or can easily be represented with triangles
> so it would be good to have a dedicated class for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-77) BoundsXD
[
https://issues.apache.org/jira/browse/GEOMETRY-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117681#comment-17117681
]
Matt Juntunen commented on GEOMETRY-77:
---
Merged in commit ed41804dc3f8273e483ddfabd331732e1ae2c550.
> BoundsXD
>
>
> Key: GEOMETRY-77
> URL: https://issues.apache.org/jira/browse/GEOMETRY-77
> Project: Apache Commons Geometry
> Issue Type: New Feature
> Components: Euclidean 2D, Euclidean 3D
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> Add classes containing min and max vectors defining axis-aligned bounding
> boxes for Euclidean 2D and 3D space.
> Ex:
> {code:java}
> public final class Bounds3D {
> private final Vector3D min;
> private final Vector3D max;
> public Vector3D getMin(){ ... }
> public Vector3D getMax(){ ... }
> public double getMinX(){ ... }
> public double getMaxX(){ ... }
> // ...
> public boolean contains(Vector3D pt) { ... }
> public boolean intersects(Bounds3D other) { ... }
>public static Bounds3D from(final Vector3D... pts) {
> // compute the min and max coordinate values from the input
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEOMETRY-77) BoundsXD
[
https://issues.apache.org/jira/browse/GEOMETRY-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed GEOMETRY-77.
-
Assignee: Matt Juntunen
> BoundsXD
>
>
> Key: GEOMETRY-77
> URL: https://issues.apache.org/jira/browse/GEOMETRY-77
> Project: Apache Commons Geometry
> Issue Type: New Feature
> Components: Euclidean 2D, Euclidean 3D
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> Add classes containing min and max vectors defining axis-aligned bounding
> boxes for Euclidean 2D and 3D space.
> Ex:
> {code:java}
> public final class Bounds3D {
> private final Vector3D min;
> private final Vector3D max;
> public Vector3D getMin(){ ... }
> public Vector3D getMax(){ ... }
> public double getMinX(){ ... }
> public double getMaxX(){ ... }
> // ...
> public boolean contains(Vector3D pt) { ... }
> public boolean intersects(Bounds3D other) { ... }
>public static Bounds3D from(final Vector3D... pts) {
> // compute the min and max coordinate values from the input
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEOMETRY-77) BoundsXD
[
https://issues.apache.org/jira/browse/GEOMETRY-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-77.
---
Resolution: Done
> BoundsXD
>
>
> Key: GEOMETRY-77
> URL: https://issues.apache.org/jira/browse/GEOMETRY-77
> Project: Apache Commons Geometry
> Issue Type: New Feature
> Components: Euclidean 2D, Euclidean 3D
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> Add classes containing min and max vectors defining axis-aligned bounding
> boxes for Euclidean 2D and 3D space.
> Ex:
> {code:java}
> public final class Bounds3D {
> private final Vector3D min;
> private final Vector3D max;
> public Vector3D getMin(){ ... }
> public Vector3D getMax(){ ... }
> public double getMinX(){ ... }
> public double getMaxX(){ ... }
> // ...
> public boolean contains(Vector3D pt) { ... }
> public boolean intersects(Bounds3D other) { ... }
>public static Bounds3D from(final Vector3D... pts) {
> // compute the min and max coordinate values from the input
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-97) Use Centroid instead of Barycenter
[
https://issues.apache.org/jira/browse/GEOMETRY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117683#comment-17117683
]
Matt Juntunen commented on GEOMETRY-97:
---
Merged in commit a70cea937b5621289a0be2e97b1a5f373b35b732.
> Use Centroid instead of Barycenter
> --
>
> Key: GEOMETRY-97
> URL: https://issues.apache.org/jira/browse/GEOMETRY-97
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> In geometry, the terms "centroid" and "barycenter" are synonyms referring to
> the center of mass of a geometric object. The code currently uses
> "barycenter" when referring to the center of mass (ex:
> {{region.getBarycenter()}}). However, "centroid" seems to be used more
> frequently. For example, one is far more likely to find relevant results when
> searching Google for "polygon centroid" than "polygon barycenter". Also,
> "barycenter" has an alternate meaning in astrophysics, where it refers to the
> center of mass of two or more orbiting objects. It seems to me like
> "centroid" is a better, more geometry-focused term to use in the code.
> See [centroid.|https://en.wikipedia.org/wiki/Centroid].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEOMETRY-97) Use Centroid instead of Barycenter
[
https://issues.apache.org/jira/browse/GEOMETRY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-97.
---
Resolution: Done
> Use Centroid instead of Barycenter
> --
>
> Key: GEOMETRY-97
> URL: https://issues.apache.org/jira/browse/GEOMETRY-97
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> In geometry, the terms "centroid" and "barycenter" are synonyms referring to
> the center of mass of a geometric object. The code currently uses
> "barycenter" when referring to the center of mass (ex:
> {{region.getBarycenter()}}). However, "centroid" seems to be used more
> frequently. For example, one is far more likely to find relevant results when
> searching Google for "polygon centroid" than "polygon barycenter". Also,
> "barycenter" has an alternate meaning in astrophysics, where it refers to the
> center of mass of two or more orbiting objects. It seems to me like
> "centroid" is a better, more geometry-focused term to use in the code.
> See [centroid.|https://en.wikipedia.org/wiki/Centroid].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEOMETRY-97) Use Centroid instead of Barycenter
[
https://issues.apache.org/jira/browse/GEOMETRY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen closed GEOMETRY-97.
-
Assignee: Matt Juntunen
> Use Centroid instead of Barycenter
> --
>
> Key: GEOMETRY-97
> URL: https://issues.apache.org/jira/browse/GEOMETRY-97
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> In geometry, the terms "centroid" and "barycenter" are synonyms referring to
> the center of mass of a geometric object. The code currently uses
> "barycenter" when referring to the center of mass (ex:
> {{region.getBarycenter()}}). However, "centroid" seems to be used more
> frequently. For example, one is far more likely to find relevant results when
> searching Google for "polygon centroid" than "polygon barycenter". Also,
> "barycenter" has an alternate meaning in astrophysics, where it refers to the
> center of mass of two or more orbiting objects. It seems to me like
> "centroid" is a better, more geometry-focused term to use in the code.
> See [centroid.|https://en.wikipedia.org/wiki/Centroid].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-vfs] PeterAlfredLee commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
PeterAlfredLee commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634625589 > IMO seems the biggest bc-breaking in this pr is changing JarFileObject's super class from ZipFileObject to AbstractFileObject, thus codes like this will break Agreed. And as I said - seems we got no other options if we want to use `Commons Compress`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (COMPRESS-529) Tar decompression fails with runtime exceptions
[
https://issues.apache.org/jira/browse/COMPRESS-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116739#comment-17116739
]
Peter Lee edited comment on COMPRESS-529 at 5/27/20, 12:48 PM:
---
> _In this particular case I disagree. I think an {{IllegalArgumentException}}
>is fine if you invoke one of the {{putArchiveEntry}} variants. We might need
>to add more documentation, granted, but this is not an I/O error of any kind
>and the caller is in full control of what it passes in as argument._
+1. I can't see any help if we change from RuntimeException to IOException -
users will still be confused if they do not know there's such a thing like long
file mode. More documentation is what we need here.
-And the NumberFormatException.tar problem is fixed in commit
b8a0b54c59191cb8338585eab055897737730a9e.-
Edit : the commit has broken the compatibility
was (Author: peterlee):
> _In this particular case I disagree. I think an {{IllegalArgumentException}}
>is fine if you invoke one of the {{putArchiveEntry}} variants. We might need
>to add more documentation, granted, but this is not an I/O error of any kind
>and the caller is in full control of what it passes in as argument._
+1. I can't see any help if we change from RuntimeException to IOException -
users will still be confused if they do not know there's such a thing like long
file mode. More documentation is what we need here.
And the NumberFormatException.tar problem is fixed in commit
b8a0b54c59191cb8338585eab055897737730a9e.
> Tar decompression fails with runtime exceptions
> ---
>
> Key: COMPRESS-529
> URL: https://issues.apache.org/jira/browse/COMPRESS-529
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Attachments: LongName.tar, NumberFormatException.tar, japicmp.html,
> japicmp.html
>
>
> This Kotlin code fails with exception(NumberFormatException.tar is in the
> attachment)
> Exception in thread "main" java.lang.NumberFormatException: For input string:
> "143266�921.098285006"
> at
> java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
> at
> java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.base/java.lang.Double.parseDouble(Double.java:543)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.processPaxHeader(TarArchiveEntry.java:1161)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.updateEntryFromPaxHeaders(TarArchiveEntry.java:1093)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.applyPaxHeadersToCurrentEntry(TarArchiveInputStream.java:757)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:562)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:69)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.File
> fun main() {
> val tar = File("NumberFormatException.tar")
> ArchiveStreamFactory().createArchiveInputStream("tar",
> tar.inputStream()).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> This Kotlin code fails with exception(LongName.tar is in the attachment)
> Exception in thread "main" java.lang.RuntimeException: file name 'asidhuasih a
> sdjn osdn
> sdvs ndv
> asdjbhasdb asb iasbfi basdigf basduio
> asdkhasjdhasd
> asdjkhasnjddjasjdas
> /?' is too long ( > 100 bytes)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.handleLongName(TarArchiveOutputStream.java:683)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:358)
> at ru.example.kotlinfuzzer.tests.MainKt.test(main.kt:20)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:8)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry
> import java.io.File
> fun main() {
> test(File("LongName.tar"))
> }
> fun test(tar: File) {
> val (decompressed, name) =
> ArchiveStreamFactory().createArchiveInputStream("tar", tar.inputStream()).use
> { ais ->
> val entry = ais.nextEntry
> ais.readAllBytes() to entry.name
> }
> File.createTempFile("apache_", ".tar").also {
> ArchiveSt
[GitHub] [commons-email] garydgregory commented on a change in pull request #16: Update code for Java 7 and other clean ups.
garydgregory commented on a change in pull request #16: URL: https://github.com/apache/commons-email/pull/16#discussion_r431094784 ## File path: pom.xml ## @@ -406,6 +406,36 @@ + Review comment: @XenoAmess The PR looks good but I am wondering why we need to configure the Javadoc plugin here. If there is something missing in the parent POM, we should fix it there. What is this doing for you that the parent is not? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] coveralls edited a comment on pull request #159: Updated the fail() exceptions with Junit5.
coveralls edited a comment on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-625612511 [](https://coveralls.io/builds/31061407) Coverage increased (+0.03%) to 90.119% when pulling **ccb7eab8d8a6f9a684ba67ce90869f3f7e26e4e2 on dota17:junit5WithExceptions** into **9f37668d9243fc71178f0e94a2b560ef861a639a on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess commented on a change in pull request #16: Update code for Java 7 and other clean ups.
XenoAmess commented on a change in pull request #16: URL: https://github.com/apache/commons-email/pull/16#discussion_r431136407 ## File path: pom.xml ## @@ -406,6 +406,36 @@ + Review comment: > @XenoAmess > The PR looks good but I am wondering why we need to configure the Javadoc plugin here. If there is something missing in the parent POM, we should fix it there. What is this doing for you that the parent is not? @garydgregory Yes I do have a reason to do so. to repreduce what I met, please follow the steps below: (my environment win10x64, openjdk13, but I don't think environment will matter much in this problem) 1. clone this pr in your pc. 2. see what I changed in this line: https://github.com/apache/commons-email/pull/16/files/6a9fe4a9ff73a1119c3624f8d861b01d7c6715fd#diff-77fad0477b22b44d8e52db08a61ff77eL63 3. please revert it back to the line content which before I commit the change, means `/** pattern for extracting tags */` . 4. run `mvn package` for this repo. 5. see the build error reported. 6. please go delete the maven-javadoc-plugin in pom.xml. 7. run `mvn package` for this repo. 8. see the build success reported. So for conclusion, I add this plugin here in this pom to [force javadoc be correct], by forcing maven fail if [javadoc be uncorrect]. I have no idea whether we can change something in commons-parent to have a same outcome without adding javadoc plugin in this repo. I'm not that familiar with complex maven management. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess commented on a change in pull request #16: Update code for Java 7 and other clean ups.
XenoAmess commented on a change in pull request #16: URL: https://github.com/apache/commons-email/pull/16#discussion_r431136407 ## File path: pom.xml ## @@ -406,6 +406,36 @@ + Review comment: > @XenoAmess > The PR looks good but I am wondering why we need to configure the Javadoc plugin here. If there is something missing in the parent POM, we should fix it there. What is this doing for you that the parent is not? @garydgregory Yes I do have a reason to do so. to repreduce what I met, please follow the steps below: (my environment win10x64, openjdk13, but I don't think environment will matter much in this problem) 1. clone this pr in your pc. 2. see what I changed in this line: https://github.com/apache/commons-email/pull/16/files/6a9fe4a9ff73a1119c3624f8d861b01d7c6715fd#diff-77fad0477b22b44d8e52db08a61ff77eL63 3. please revert it back to the line content which before I commit the change, means `/** pattern for extracting tags */` . 4. run `mvn package` for this repo. 5. see the build error reported. 6. please go delete the maven-javadoc-plugin in pom.xml. 7. run `mvn package` for this repo. 8. see the build success reported. So for conclusion, I add this plugin here in this pom to [force javadoc be correct], by forcing maven fail if [javadoc be uncorrect]. I have no idea whether we can change something in commons-parent to have a same outcome without adding javadoc plugin in this repo. I'm not that familiar with complex maven repos management. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess commented on pull request #13: [EMAIL-192] add maven-javadoc-plugin; fix errors about javadoc in this project.
XenoAmess commented on pull request #13: URL: https://github.com/apache/commons-email/pull/13#issuecomment-634667244 merged to https://github.com/apache/commons-email/pull/16. so we just close this pr. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess closed pull request #13: [EMAIL-192] add maven-javadoc-plugin; fix errors about javadoc in this project.
XenoAmess closed pull request #13: URL: https://github.com/apache/commons-email/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] ecki commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
ecki commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634676773 We can add a different provider, then each developer can configure the provider for the jar schema as needed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634679615 Before we This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory closed pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory closed pull request #91: URL: https://github.com/apache/commons-vfs/pull/91 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634680133 > We can add a different provider, then each developer can configure the provider for the jar schema as needed. Before someone goes that route, it seems fair to try to update to Commons Compress without breaking BC. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634693620 Darn, I did not mean to close the PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] XenoAmess commented on pull request #16: Update code for Java 7 and other clean ups.
XenoAmess commented on pull request #16: URL: https://github.com/apache/commons-email/pull/16#issuecomment-634695470 I'm making some unit tests for the regex I added. I do hope they will be all correct, but I need some tests to proove it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (STATISTICS-24) Documentation mistake maybe
[ https://issues.apache.org/jira/browse/STATISTICS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117809#comment-17117809 ] Wu Tao commented on STATISTICS-24: -- Yes, I'm interested in implementing statistics libraries using the Java 8 schema. It's really something that modern Java needs for data science. I've roughly went through the current commons-math4 and commons-statistics-parent branch. It seems that you've already ported the distribution sub-package from commons.math4.stat, but the other sub-packages' porting, such as descriptive and regression, seems more challenging, as described in ML and jira issues. Should I discuss them in these pending jira issues, or just post new proposal in the dev ML?[~erans] > Documentation mistake maybe > --- > > Key: STATISTICS-24 > URL: https://issues.apache.org/jira/browse/STATISTICS-24 > Project: Apache Commons Statistics > Issue Type: Bug >Reporter: Wu Tao >Priority: Trivial > > Hi all! > When I followed the Developers Guide at > [http://commons.apache.org/proper/commons-statistics/developers.html], the > doc told me to get the code from > [http://gitbox.apache.org/repos/asf/commons-rng.git.|http://gitbox.apache.org/repos/asf/commons-rng.git,] > I'm wondering why I can only get the rng instead of the statistics module. > Is that a documentation mistake? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-vfs] garydgregory commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634697490 Maybe what we need is a Commons Compress provider..., then all that Commons Compress can do we can surface from a single provider. Thoughts? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (DBCP-565) application stuck with normal load
zhiqian huang created DBCP-565: -- Summary: application stuck with normal load Key: DBCP-565 URL: https://issues.apache.org/jira/browse/DBCP-565 Project: Commons DBCP Issue Type: Bug Reporter: zhiqian huang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-email] XenoAmess commented on pull request #16: Update code for Java 7 and other clean ups.
XenoAmess commented on pull request #16: URL: https://github.com/apache/commons-email/pull/16#issuecomment-634699240 tests for new added functions done. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DBCP-565) application stuck with normal load
[ https://issues.apache.org/jira/browse/DBCP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117814#comment-17117814 ] Gary D. Gregory commented on DBCP-565: -- [~hzq] Unless you can provide a reproducible test case, then this kind of ticket without even a description is useless and will be deleted. Tests as patches on GitHub are best, using a local database like H2 is best as well. > application stuck with normal load > -- > > Key: DBCP-565 > URL: https://issues.apache.org/jira/browse/DBCP-565 > Project: Commons DBCP > Issue Type: Bug >Reporter: zhiqian huang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DBCP-565) application stuck with normal load
[ https://issues.apache.org/jira/browse/DBCP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiqian huang updated DBCP-565: --- Description: one application in cluster(8) stuck commons-dbcp 1.4 commons-pool 1.5.4 the connection to mysql-server slow continuous grows ，about 30 minutes later，the application stuck 。 I check the mysql-server log，find some transaction not commit。the execution log like this： set autocommit = 0 ; update x; logout ( FAIL ) for 30 minutes (finally restart the application) > application stuck with normal load > -- > > Key: DBCP-565 > URL: https://issues.apache.org/jira/browse/DBCP-565 > Project: Commons DBCP > Issue Type: Bug >Reporter: zhiqian huang >Priority: Major > > one application in cluster(8) stuck > commons-dbcp 1.4 commons-pool 1.5.4 > > the connection to mysql-server slow continuous grows ，about 30 minutes > later，the application stuck 。 > I check the mysql-server log，find some transaction not commit。the > execution log like this： > set autocommit = 0 ; > update x; > logout ( FAIL ) for 30 minutes (finally restart the application) > > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DBCP-565) application stuck with normal load
[ https://issues.apache.org/jira/browse/DBCP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiqian huang updated DBCP-565: --- Description: one application in cluster(8) stuck commons-dbcp 1.4 commons-pool 1.5.4 the connection to mysql-server slow continuous grows ，about 30 minutes later，the application stuck 。 I check the mysql-server log，find some transaction not commit。the execution log like this： set autocommit = 0 ; update x; logout ( FAIL ) for 30 minutes (finally restart the application)。 Emegencying to handle the production fault，no stacktrace keeps。 was: one application in cluster(8) stuck commons-dbcp 1.4 commons-pool 1.5.4 the connection to mysql-server slow continuous grows ，about 30 minutes later，the application stuck 。 I check the mysql-server log，find some transaction not commit。the execution log like this： set autocommit = 0 ; update x; logout ( FAIL ) for 30 minutes (finally restart the application) > application stuck with normal load > -- > > Key: DBCP-565 > URL: https://issues.apache.org/jira/browse/DBCP-565 > Project: Commons DBCP > Issue Type: Bug >Reporter: zhiqian huang >Priority: Major > > one application in cluster(8) stuck > commons-dbcp 1.4 commons-pool 1.5.4 > > the connection to mysql-server slow continuous grows ，about 30 minutes > later，the application stuck 。 > I check the mysql-server log，find some transaction not commit。the > execution log like this： > set autocommit = 0 ; > update x; > logout ( FAIL ) for 30 minutes (finally restart the application)。 > Emegencying to handle the production fault，no stacktrace keeps。 > > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-vfs] XenoAmess edited a comment on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
XenoAmess edited a comment on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634709959 > Maybe what we need is a Commons Compress provider..., then all that Commons Compress can do we can surface from a single provider. Thoughts? Good idea, that reminds me the good old days when I be at ms...forking a provider for odatav4 from what for odatav2. That sounds both neat and convenient. But in that way we got a samilar problem I asked several hours ago in dev-mail: where should we put this provider? in commons-vfs? or in commons-compress? or create a new repo for such classes? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] XenoAmess commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
XenoAmess commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634709959 > Maybe what we need is a Commons Compress provider..., then all that Commons Compress can do we can surface from a single provider. Thoughts? Good idea, that reminds me the good old days when I be at ms...forking a provider for odatav4 from That sounds both neat and convenient. But in that way we got a samilar problem I asked several hours ago in dev-mail: where should we put this provider? in commons-vfs? or in commons-compress? or create a new repo for such classes? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] XenoAmess edited a comment on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
XenoAmess edited a comment on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634709959 > Maybe what we need is a Commons Compress provider..., then all that Commons Compress can do we can surface from a single provider. Thoughts? Good idea, that reminds me the good old days when I be at ms...forking a provider for odatav4 from what for odatav2. That sounds both neat and convenient. But in that way we got a samilar problem I asked several hours ago in dev-mail: where should we put this provider? in commons-vfs? or in commons-compress? or create a new repo for such classes? maybe we shall put it as a submodule like vfs-jackrabbit? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] ecki commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
ecki commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634714292 gary, that was my idea so yes. since we already have multiple providers for http thats fine for compression too. It might not wortk for the util.VFSClassLoader util class as that is not related to an classloader, but this one could be changed to introspect the Jar file for signature checking (i think it had some dependency in there but i can be wrong) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] ecki commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
ecki commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-634720978 Commons-compress is already a dependency, so it would not hurt to put the alternative provider in core (in this case) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DBCP-565) application stuck with normal load
[ https://issues.apache.org/jira/browse/DBCP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117858#comment-17117858 ] Gary D. Gregory commented on DBCP-565: -- [~hzq] Thank you for adding a description to this ticket. Version 1.x is no longer maintained (at least not by me), please update to 2.x and let us know if this still happens. > application stuck with normal load > -- > > Key: DBCP-565 > URL: https://issues.apache.org/jira/browse/DBCP-565 > Project: Commons DBCP > Issue Type: Bug >Reporter: zhiqian huang >Priority: Major > > one application in cluster(8) stuck > commons-dbcp 1.4 commons-pool 1.5.4 > > the connection to mysql-server slow continuous grows ，about 30 minutes > later，the application stuck 。 > I check the mysql-server log，find some transaction not commit。the > execution log like this： > set autocommit = 0 ; > update x; > logout ( FAIL ) for 30 minutes (finally restart the application)。 > Emegencying to handle the production fault，no stacktrace keeps。 > > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (STATISTICS-24) Documentation mistake maybe
[ https://issues.apache.org/jira/browse/STATISTICS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117952#comment-17117952 ] Gilles Sadowski commented on STATISTICS-24: --- bq. Should I discuss them in these pending jira issues, or just post new proposal in the dev ML? I suggest that you post to the ML, indicating your intent to contribute to the [Statistics] component. We can (re)discuss there the overall plan. Specific tasks are then created/commented here. > Documentation mistake maybe > --- > > Key: STATISTICS-24 > URL: https://issues.apache.org/jira/browse/STATISTICS-24 > Project: Apache Commons Statistics > Issue Type: Bug >Reporter: Wu Tao >Priority: Trivial > > Hi all! > When I followed the Developers Guide at > [http://commons.apache.org/proper/commons-statistics/developers.html], the > doc told me to get the code from > [http://gitbox.apache.org/repos/asf/commons-rng.git.|http://gitbox.apache.org/repos/asf/commons-rng.git,] > I'm wondering why I can only get the rng instead of the statistics module. > Is that a documentation mistake? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (VALIDATOR-467) URL validator fails if path starts with double slash
Ivan Larionov created VALIDATOR-467:
---
Summary: URL validator fails if path starts with double slash
Key: VALIDATOR-467
URL: https://issues.apache.org/jira/browse/VALIDATOR-467
Project: Commons Validator
Issue Type: Bug
Components: Routines
Affects Versions: 1.6
Reporter: Ivan Larionov
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns `false`. However such URL is valid if authority is not {{null}}.
> The reason it returns false is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns `false`. However such URL is valid if authority is not {{null}}.
> The reason it returns false is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns `false`. However such URL is valid if authority is not {{null}}.
The reason it returns false is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns false is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
> {{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
> {{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
> I didn't read RFC but from some googling around I got the following:
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI((String)null, "example.com", path, (String)null);}}
and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
> {{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
> I tried running {{new URI((String)null, "example.com", path, (String)null);}}
> and it worked.
> I didn't read RFC but from some googling around I got the following
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI((String)null, "example.com", path, (String)null);}}
and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
> {{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
> I tried running {{new URI(null, "example.com", path, null);}} and it worked.
> I didn't
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
Update:
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
Update:
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is th
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
Update:
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is t
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
Update:
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test//double//slashes"}}
And that {{"https://example.com//test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
I guess better description would be "URL validator incorrectly uses URI uri =
new URI(null,null,path,null); check due to these nulls in arguments".
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {cod
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
I guess better description would be "URL validator incorrectly uses URI uri =
new URI(null,null,path,null); check due to these nulls in arguments".
And the simplest URL to test is
{{https://example.com//test_double_slash_and_underscore}}
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
I guess better description would be "URL validator incorrectly uses URI uri =
new URI(null,null,path,null); check due to these nulls in arguments".
> URL validator fails if path starts with double slash
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"ht
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash and has underscores
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Summary: URL validator fails if path starts with double slash and has
underscores (was: URL validator fails if path starts with double slash)
> URL validator fails if path starts with double slash and has underscores
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan Larionov
>Priority: Major
>
> {code:java}
> import org.apache.commons.validator.routines.UrlValidator;
> ...
> private static final String[] schemes = {"http", "https"};
> private static final UrlValidator urlValidator = new UrlValidator(schemes,
> UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
> ...
> urlValidator.isValid("https://example.com//some_path/path/";)
> {code}
> This returns {{false}}. However such URL is valid if authority is not
> {{null}}.
> The reason it returns {{false}} is this code in the validator:
> https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
> {code:java}
> try {
> URI uri = new URI(null,null,path,null);
> String norm = uri.normalize().getPath();
> if (norm.startsWith("/../") // Trying to go via the parent dir
> || norm.equals("/..")) { // Trying to go to the parent dir
> return false;
> }
> } catch (URISyntaxException e) {
> return false;
> }
> {code}
> As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
> {{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
> I tried running {{new URI(null, "example.com", path, null);}} and it worked.
> I didn't read RFC but from some googling around I got the following:
> {{//some_path}} is invalid if authority is null
> {{//some_path}} is valid if authority is not null
> *Update:*
> Another thing I noticed while testing is that the following actually passes
> the validation – {{"https://example.com//test"}}
> And that {{"https://example.com//test_test"}} fails the validation but
> {{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
> not due to {{//}} at the start.
> So my original theory behind the failure looks incorrect now, however I still
> consider this bug as a valid one.
> I guess better description would be "URL validator incorrectly uses URI uri =
> new URI(null,null,path,null); check due to these nulls in arguments".
> And the simplest URL to test is
> {{https://example.com//test_double_slash_and_underscore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VALIDATOR-467) URL validator fails if path starts with double slash and has underscores
[
https://issues.apache.org/jira/browse/VALIDATOR-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Larionov updated VALIDATOR-467:
Description:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
I guess better description would be "URL validator incorrectly uses URI uri =
new URI(null,null,path,null); check. Due to these nulls in arguments path is
validated as a hostname".
And the simplest URL to test is
{{https://example.com//test_double_slash_and_underscore}}
was:
{code:java}
import org.apache.commons.validator.routines.UrlValidator;
...
private static final String[] schemes = {"http", "https"};
private static final UrlValidator urlValidator = new UrlValidator(schemes,
UrlValidator.ALLOW_LOCAL_URLS + UrlValidator.ALLOW_2_SLASHES);
...
urlValidator.isValid("https://example.com//some_path/path/";)
{code}
This returns {{false}}. However such URL is valid if authority is not {{null}}.
The reason it returns {{false}} is this code in the validator:
https://github.com/apache/commons-validator/blob/a3771313c9f1833abf32c7c294ad1de4810e532d/src/main/java/org/apache/commons/validator/routines/UrlValidator.java#L452-L461
{code:java}
try {
URI uri = new URI(null,null,path,null);
String norm = uri.normalize().getPath();
if (norm.startsWith("/../") // Trying to go via the parent dir
|| norm.equals("/..")) { // Trying to go to the parent dir
return false;
}
} catch (URISyntaxException e) {
return false;
}
{code}
As far as I understand {{URI uri = new URI(null,null,path,null);}} throws
{{URISyntaxException}} if authority is {{null}} and path starts with {{//}}.
I tried running {{new URI(null, "example.com", path, null);}} and it worked.
I didn't read RFC but from some googling around I got the following:
{{//some_path}} is invalid if authority is null
{{//some_path}} is valid if authority is not null
*Update:*
Another thing I noticed while testing is that the following actually passes the
validation – {{"https://example.com//test"}}
And that {{"https://example.com//test_test"}} fails the validation but
{{URISyntaxException}} is thrown due to {{Illegal character in hostname}} and
not due to {{//}} at the start.
So my original theory behind the failure looks incorrect now, however I still
consider this bug as a valid one.
I guess better description would be "URL validator incorrectly uses URI uri =
new URI(null,null,path,null); check due to these nulls in arguments".
And the simplest URL to test is
{{https://example.com//test_double_slash_and_underscore}}
> URL validator fails if path starts with double slash and has underscores
>
>
> Key: VALIDATOR-467
> URL: https://issues.apache.org/jira/browse/VALIDATOR-467
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Ivan La
[GitHub] [commons-vfs] PeterAlfredLee commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
PeterAlfredLee commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-635036711 > Maybe what we need is a Commons Compress provider..., then all that Commons Compress can do we can surface from a single provider. Thoughts? Indeed it's a good idea. Thank you guys for your suggestions! Will update in this PR in the following days ... hoping I could finish this whthin this week. > where should we put this provider? I think it should belong VFS. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (DBCP-565) application stuck with normal load
[ https://issues.apache.org/jira/browse/DBCP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhiqian huang closed DBCP-565. -- Resolution: Invalid > application stuck with normal load > -- > > Key: DBCP-565 > URL: https://issues.apache.org/jira/browse/DBCP-565 > Project: Commons DBCP > Issue Type: Bug >Reporter: zhiqian huang >Priority: Major > > one application in cluster(8) stuck > commons-dbcp 1.4 commons-pool 1.5.4 > > the connection to mysql-server slow continuous grows ，about 30 minutes > later，the application stuck 。 > I check the mysql-server log，find some transaction not commit。the > execution log like this： > set autocommit = 0 ; > update x; > logout ( FAIL ) for 30 minutes (finally restart the application)。 > Emegencying to handle the production fault，no stacktrace keeps。 > > > > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-cli] XenoAmess commented on pull request #38: fix travis-ci scripts
XenoAmess commented on pull request #38: URL: https://github.com/apache/commons-cli/pull/38#issuecomment-635115194 > along with this we should add > ` before_cache: rm -rfv $HOME/.m2/repository/org/apache/commons/cli` Is it necessary? and why？ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (CRYPTO-148) Releasing Commons Crypto with AArch64 support
[ https://issues.apache.org/jira/browse/CRYPTO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] odidev updated CRYPTO-148: -- Attachment: Dockerfile docker-compose.yaml build-instructions-apache-commons-crypto.docx > Releasing Commons Crypto with AArch64 support > - > > Key: CRYPTO-148 > URL: https://issues.apache.org/jira/browse/CRYPTO-148 > Project: Commons Crypto > Issue Type: Task > Components: Build >Affects Versions: 1.1.0 > Environment: Linux, AArch64 >Reporter: odidev >Priority: Major > Labels: Release > Fix For: 1.1.0 > > Attachments: Dockerfile, > build-instructions-apache-commons-crypto.docx, docker-compose.yaml > > > Currently, Commons Crypto 1.0.0 is available in maven's repository which > doesn't have AArch64 support but Commons Crypto 1.1.0 look have AArch64 > support. Can you please let me know if when it is getting released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CRYPTO-148) Releasing Commons Crypto with AArch64 support
[ https://issues.apache.org/jira/browse/CRYPTO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118369#comment-17118369 ] odidev commented on CRYPTO-148: --- Please find attached document/docker files for cross compilation of Commons Crypto for AArch64 machine. > Releasing Commons Crypto with AArch64 support > - > > Key: CRYPTO-148 > URL: https://issues.apache.org/jira/browse/CRYPTO-148 > Project: Commons Crypto > Issue Type: Task > Components: Build >Affects Versions: 1.1.0 > Environment: Linux, AArch64 >Reporter: odidev >Priority: Major > Labels: Release > Fix For: 1.1.0 > > Attachments: Dockerfile, > build-instructions-apache-commons-crypto.docx, docker-compose.yaml > > > Currently, Commons Crypto 1.0.0 is available in maven's repository which > doesn't have AArch64 support but Commons Crypto 1.1.0 look have AArch64 > support. Can you please let me know if when it is getting released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CRYPTO-148) Releasing Commons Crypto with AArch64 support
[ https://issues.apache.org/jira/browse/CRYPTO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118369#comment-17118369 ] odidev edited comment on CRYPTO-148 at 5/28/20, 6:34 AM: - Please find attached document/docker files for cross compilation of Commons Crypto for AArch64 machine. Build instructions: [^build-instructions-apache-commons-crypto.docx] was (Author: odidev): Please find attached document/docker files for cross compilation of Commons Crypto for AArch64 machine. > Releasing Commons Crypto with AArch64 support > - > > Key: CRYPTO-148 > URL: https://issues.apache.org/jira/browse/CRYPTO-148 > Project: Commons Crypto > Issue Type: Task > Components: Build >Affects Versions: 1.1.0 > Environment: Linux, AArch64 >Reporter: odidev >Priority: Major > Labels: Release > Fix For: 1.1.0 > > Attachments: Dockerfile, > build-instructions-apache-commons-crypto.docx, docker-compose.yaml > > > Currently, Commons Crypto 1.0.0 is available in maven's repository which > doesn't have AArch64 support but Commons Crypto 1.1.0 look have AArch64 > support. Can you please let me know if when it is getting released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
