none
Could it be the %2F?

    Question

  • My site works great on the intranet, but when I put it on the internet some pages will not display.  The users can hit the domain name "sharepoint.somesite.foo", but when the user goes in a document library directory structure or several directories into web folders -- pages will not render.  I think i diagnosted the problem to the markup language found in the query parameter of the RootFolder request.

     

    What character is the %2f supposed to be here?

    AllItems.aspx?RootFolder=%2fSomeFolder%5ForUsers%2fABC%5f

     

    Any response is welcomed because I may be barking up the wrong tree anyway.

    Wednesday, April 02, 2008 4:16 PM

Answers

  • I totally missed this one and ended up in the bleachers past right field..  But, here's a solution.

     

    Running WSS on a intranet is great, but if it goes live on the internet there could be some problems if the computer name of the WSS machine ends up in the URL of the internet connection.  (Which is what happened here)

     

    To make a quick resolve for this problem I edited the host file and put the IP address of my site to the computer name of my WSS machine.  Now, if one of the users of our organization accidentally runs across the computer name while accessing WSS via internet, then their machine will use the IP instead of the computer name.

     

    However, how can I stop the WSS3.0 site from making the 'computer name' show up in the URL?  NATs and editing host files is all good.. but, surely there's a way to make WSS always use the FQDN.  Any Ideas?

     

    Friday, April 11, 2008 12:08 AM

All replies

  • That would be the backslah ( / <-- I get dyslexic when it comes to my computer slashes)

     

    You can find all of the hex to ascii mappings here: http://www.asciitable.com/

     

    You'll also see a lot of hex characters in place of a curly brace (%7B) when guids are references

     

    Edit: and yea, I'm pretty sure it is supposed to be there, since that RootFolder query string defines the path to the library

    Wednesday, April 02, 2008 4:41 PM
  • Thank for that link!  I looked around the w3c for it but couldn't ever get to where I wanted to go.  I can troubleshoot the problem now by replacing the encoded characters with actual characters and see if that's the problem.

     

    Wednesday, April 02, 2008 4:45 PM
  •  

    No problem Darian, anytime you see a % in the query string when referencing a SP site, that is always a hex encoded character. So %xx always equates to one singular character.  You can use that ascii table to easily map the two character code to the the actuall ascii character.

     

    That said, you won't be able to just punch those slash characters into the URL string because internet explorer won't get along with the url, so my guess is your problem is somewhere else...

    Wednesday, April 02, 2008 4:51 PM
  • The ascii encoded characters in my url string is the problem.  I replaced all the forward slashes, dashes, underscores, and even the curly braces at the end.. and now the page renders great.

     

    So, How do I make SharePoints DataSourcePaths render the exact character instead of the ascii encoded character?

    Wednesday, April 02, 2008 5:01 PM
  • Darian,

     

    Were any of the characters prior to the AllItems.aspx portion of the url escaped?

     

    -J

    Wednesday, April 02, 2008 5:19 PM
  • No, only the characters after the AllItems.aspx.. Is this an IIS issue?  or can i manually change the strings in the DataPaths?

     

    Wednesday, April 02, 2008 6:01 PM
  • I'm not sure how you could manually change the strings... the url might be built in one of the core.js or ows.js files, but modifying those is not recommended.

     

    A cursory google search indicates that this might be an ASP.NET or an IIS issue with how your internet facing site is configured.  Consider that if you type: http://forums.microsoft.com/msdn%2fdefault.aspx?siteid=1 (or copy and paste) into your browser, then the url is parsed properly.  that is, it treats that %2f as a forward slash (/) and finds default.aspx correctly.  I wonder if it could possibly be a setting in the web.config or possibly something on your firewall that is preventing those characters from even getting to IIS?

     

    Edit:  Could URLScan be running?  I got some hits on this IIS LockDown tool that indicated URLScan could be preventing those characters from being properly decoded by IIS/ASP.NET

     

    http://www.microsoft.com/technet/security/tools/locktool.mspx (includes URLScan)

    Wednesday, April 02, 2008 6:16 PM
  • I found the document I need to change, but not sure what to do.


    The directory structure is root/DocumentLibraryName/FoldersOfDocumentLibrary/Forms/AllItems.aspx.


    When I open that file (AllItems.aspx) in SharePoint Designer I see all of the <a href="FolderNames"> from the DocumentLibrary.  These are the links that I need to edit and get rid of the ASCII references. 

     

    But, instead of trying to change the parameters of strings passed between HTML pages within WSS 3.0 ... I am going to start a new thread on the iis.net site and see why my site won't locate pages when there is ascii encoding in the urls.


    I was hoping there was a setting in WSS that allowed me to make stronger URLs.


    Ill leave this post open for a couple more days incase someone else finds me and has the solution.

    Wednesday, April 02, 2008 7:40 PM
  • It's not IIS.  I created a new web site and created several documents with all kinds of different symbols.. spaces, braces, dashes, ets.  All the documents opened fine.  In fact, most of the pages open with no problem from the WSS virtual directory site. 

     

    The problem has to do with when I use a FQDN to access my WSS3.0 site, and I have narrowed down to the Forms folder created in a Document Library. 

     

    I think this is the process.. correct me if I'm wrong please...

    The AllItems.aspx from the Forms Folder in a Document Library uses the AllItems.aspx file found in the masterpage (master page gallery) folder, and the AllItems.aspx file in the masterpage(master page gallery)  folder uses the default.master of the masterpage folder.

     

    The asp:ContentPlaceHolder id="PlaceHolderMain" of the masterpage(master page gallery) is looking for the web part ID from the AllItems.aspx file found in the Forms folder of the Document Library.  If the Web Part ID has the ASCII encoded characters then the asp:ContentPlaceHolder id="PlaceHolderMain" will not be able to render the content of the DocumentLibrary/Forms/AllItems.aspx web part.

     

    So, could it be that when I am using a LAN to access the ServerName is able to find the LONG WEB PART ID of the AllItems.aspx file in the Forms Folder of the Document Library because it's local, but when the URL contains a FQDN the server cannot access the LONG WEB PART ID of the AllItems.aspx file in the Forms Folder of the Document Library because it contains the ASCII encoded charaters?

     

    Example:

    This link works when it's on the LAN

    http://ServerName/DocumentLibraryName/Forms/AllItems.aspx?RootFolder=%2fDocumentLibraryName%2fDocumentLibraryFolderName&FolderCTID=0x012000B6B5C9259F680E4B87B47F1F832205A3&View=%7bFF56FB8E%2d2C5A%2d45A0%2d97D3%2d9DF5D0DB757A%7d

     

    Now.. If I replace all the ASCII encoding with actual characters it works on the Internet ...

    http://Sharepoint.ServerName.com/DocumentLibraryName/Forms/AllItems.aspx?RootFolder=/DocumentLibraryName/DocumentLibraryFolderName&FolderCTID=0x012000B6B5C9259F680E4B87B47F1F832205A3&View={FF56FB8E-2C5A-45A0-97D3-9DF5D0DB757A}

     

    But, it won't work on the internet unless the ASCII encoding is replaced with actual characters. 

     

    PLEASE, HELP ME.

    Wednesday, April 02, 2008 9:07 PM
  • I totally missed this one and ended up in the bleachers past right field..  But, here's a solution.

     

    Running WSS on a intranet is great, but if it goes live on the internet there could be some problems if the computer name of the WSS machine ends up in the URL of the internet connection.  (Which is what happened here)

     

    To make a quick resolve for this problem I edited the host file and put the IP address of my site to the computer name of my WSS machine.  Now, if one of the users of our organization accidentally runs across the computer name while accessing WSS via internet, then their machine will use the IP instead of the computer name.

     

    However, how can I stop the WSS3.0 site from making the 'computer name' show up in the URL?  NATs and editing host files is all good.. but, surely there's a way to make WSS always use the FQDN.  Any Ideas?

     

    Friday, April 11, 2008 12:08 AM
  •  

    Hi Darian,

     

    Have you tried playing with Alternate Address Mapping in CA?

     

    http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx

     

    Thanks,

     

    Jonathan

    Friday, April 11, 2008 12:44 PM
  • The more I read that post ... the more I understand.  There is so much of it over my head that I've been reading it for a month now and still learning a whole bunch.

     

    I know it's a month later, but I just wanted to say thanks Jonathan for pointing me to that blog.

     

    Tuesday, May 13, 2008 3:39 PM
  • Moving the entire thread to general. This isn't customization !
    Tuesday, May 13, 2008 4:46 PM