Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pathHead is null after parsing "http:/" #8

Open
erwee opened this issue Mar 13, 2018 · 6 comments
Open

pathHead is null after parsing "http:/" #8

erwee opened this issue Mar 13, 2018 · 6 comments
Labels
invalid This doesn't seem right

Comments

@erwee
Copy link

erwee commented Mar 13, 2018

On versions 8.4.0 and 8.5.0, the following code will fail on the second assert:

    const char* url = "http:/";
    UriParserStateA state;
    UriUriA uriStruct;
    state.uri = &uriStruct;
    int err = uriParseUriA(&state, url);
    assert(err == URI_SUCCESS);
    assert(uriStruct.pathHead != NULL); // this fails

I'm expecting the pathHead to be non-null, because the input string matches the (scheme ":" path-absolute) form of the URI grammar. Also, I'm expecting the first path-segment to be an empty string.

If I changed the input string to "http:/path", or to "http:///", the above test passes.

@hartwork
Copy link
Member

hartwork commented Mar 13, 2018

Before I get to take a closer look to confirm or not confirm this as a bug, let me share this shell output:

# ./uriparse http:
uri:          http:                                                                                                                                                                           
scheme:       http                                                                                                                                                                            
absolutePath: false                                                                                                                                                                           
                                                                                                                                                                                              
# ./uriparse http:/                                                                                                                                                                           
uri:          http:/                                                                                                                                                                          
scheme:       http                                                                                                                                                                            
absolutePath: true                                                                                                                                                                            
                                                                                                                                                                                              
# ./uriparse http:/a                                                                                                                                                                          
uri:          http:/a                                                                                                                                                                         
scheme:       http                                                                                                                                                                            
 .. pathSeg:  a                                                                                                                                                                               
absolutePath: true

@hartwork
Copy link
Member

hartwork commented Mar 13, 2018

I guess I can acknowledge absolutePath as a suboptimal design but I'm tending towards: bad design, not a bug (that we could fix (without breaking ABI and making things worse)).

@erwee
Copy link
Author

erwee commented Mar 13, 2018

I suppose the problem I'm having with this is that the resulting value of pathHead after parsing a path consisting of a single "/" is not consistent between different forms of URI hier-parts. For example, for "http:///", pathHead is non-null, and pathSegment is an empty string, whereas for "http:/", pathHead comes out as NULL.

@hartwork
Copy link
Member

Could be more fun, agreed. Without breaking ABI (or even API), we cannot do anything about it, right?

@erwee
Copy link
Author

erwee commented Mar 13, 2018

Ok fine, then I guess if someone needs to check if a URI has a path, then he'd have to check both pathAbsolute flag and the pathHead pointer to see if either of them is true/non-null.. Because pathHead alone is not enough.. Might need to document this.

@hartwork
Copy link
Member

hartwork commented Mar 13, 2018

I found this comment block from 55ea6ab in the test suite:

============================================================================
Rule                                | Example | hostSet | absPath | emptySeg
------------------------------------|---------|---------|---------|---------
1) URI = scheme ":" hier-part ...   |         |         |         |
   1) "//" authority path-abempty   | "s://"  | true    |   false |   false
                                    | "s:///" | true    |   false | true
                                    | "s://a" | true    |   false |   false
                                    | "s://a/"| true    |   false | true
   2) path-absolute                 | "s:/"   |   false | true    |   false
   3) path-rootless                 | "s:a"   |   false |   false |   false
                                    | "s:a/"  |   false |   false | true
   4) path-empty                    | "s:"    |   false |   false |   false
------------------------------------|---------|---------|---------|---------
2) relative-ref = relative-part ... |         |         |         |
   1) "//" authority path-abempty   | "//"    | true    |   false |   false
                                    | "///"   | true    |   false | true
   2) path-absolute                 | "/"     |   false | true    |   false
   3) path-noscheme                 | "a"     |   false |   false |   false
                                    | "a/"    |   false |   false | true
   4) path-empty                    | ""      |   false |   false |   false
============================================================================

I guess it could use more visibility, sorry.

@hartwork hartwork added the invalid This doesn't seem right label Mar 13, 2018
@hartwork hartwork pinned this issue Jan 6, 2019
@hartwork hartwork unpinned this issue Jan 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants