Hi,
Posted this over in the Eclipse PDT newsgroups as I originally throught it was a problem with PDT but it seems like it is something more withing Xdebug. Attached is a copy of that thread.
I am curious if the changes to Xdebug are reasonable or not and if there is anything I can do to help implement them into Xdebug.
-- Shawn Clark _________________________________________________________________
attached mail follows:
Just tested and it is indeed a problem with the cookie. Within my
application I have some site wide cookies setup so that the host is
..domain.com where the first . is to signify all sub-domains. What I did
was edit my XDEBUG_SESSION cookie once it was created to add the . in
the front and now I can debug all sub-domains.
So my question now is can one or the other of the following be made
available:
- Can a flag be set within the Xdebug php.ini settings to allow a wild
card sub-domain cookie instead of the domain itself
- Can a URL argument be passed along with the XDEBUG_SESSION_START to
state that it is for all sub-domains
- With this option a setting would need to be added to the Xdebug
server configuration within PDT to tell which PHP server configurations
can pass that argument
If time is of concern then I can look at making the change to PDT if
someone is able to help with the Xdebug side of things. I did notice
there is a Firefox add-on to enable Xdebug for a specific page. I am
going to look at extending that add-on to do multiple sub-domains as
well as an interim solution.
-- Shawn Clark Shawn Clark wrote: > Ah... that is sort of what I was thinking but it wasn't working and now > I think I understand exactly what the problem is and it isn't so much a > problem with PDT as it is with Xdebug. > > When Eclipse loads the URL in the server configuration for the debug > session it passes along the information which Xdebug then puts into a > session cookie for the browser. The thing I am guessing is happening is > that the cookie is only for the current domain and not any sub-domain of > that domain. So when I am going to a sub-domain the cookie isn't being > passed to Xdebug and as such Xdebug isn't relaying the absolute path > information to the IDE. > > I am going to test now and will see if that is the case. I will just > watch where Xdebug tells the browser to assign the cookie. I am guessing > it is just for the main domain that is for the URL that is set in Eclipse. > > -- > Shawn Clark > > Dave wrote: >> Hi Shawn, I am not sure I fully understand the problem. The xdebug >> implementation doesn't make use of urls for path mapping. The only >> time the url is used is when you launch the debugger for the first >> time. This then invokes that url and turns on the xdebug cookie so >> that the browser is then in debug mode. All interaction between xdebug >> running in the web server and PDT is done by absolute file name and >> this is what the path mapper uses. So you map the absolute path in the >> web server to your workspace path in PDT. >> >> When you set a breakpoint in PDT, it can translate that to the correct >> absolute path in your server and define the correct breakpoint in the >> server. So if it is all the same code then that breakpoint will fire >> and PDT will break. >> >> PDT autogenerates a path mapping based on the file you specify in the >> web script launch and the file that gets executed when the url is >> invoked. You can of course create your own path mappings when you >> define the server. >> >> I hope this explanation helps. >> >> Dave Kelsey >> >> >> Shawn Clark wrote: >>> Hi, >>> >>> I am wondering if it is possible to setup a PDT debug session to >>> respond to multiple sub domains? >>> >>> I am working with an application that has ServerAlias' within a >>> virtual host such that any number of sub domains call the same code >>> so if I setup a breakpoint on a line of code it should break on any >>> of the sub domains. >>> >>> Currently it doesn't look like it is possible due to the fact the the >>> PHP Server configuration has a URL like http://domain.com/. What I >>> would be looking for is something like http://*.domain.com/. Then in >>> the path mapping it would just be one entry. >>> >>> -- >>> Shawn ClarkReceived on Sun Nov 23 2008 - 05:15:14 GMT
This archive was generated by hypermail 2.2.0 : Mon Jun 25 2018 - 06:00:04 BST